6 Implementing the Domain Model

 

This chapter covers

  • Implementing the domain model
  • Functions and methods
  • Designing around determinism

It's time to start writing some code! This chapter picks up where we left off in Chapter 5. We’ve finished modeling a complex invoicing domain that charges late fees. All of the data and behaviors have been sketched out. Now it’s up to us to implement them.

This requires care. A bad implementation can undermine a good data model. Methods in Java are up to no good most of the time. We’re going to learn how to get them under control.

We’re also going to spend time figuring out where to put all of this implementation code. So far, our modeling has been purposefully indifferent to details like class ownership. We focused only on the data and how it flowed through the program. But now we need to make architectural choices. Who should own these behaviors? Who can they talk to? Who can talk to them?

We’re going to learn how a really simple idea can transform both how we implement our methods and how we organize them into classes.

6.1 On the criteria by which we break down an implementation

In the last chapter, we tweaked the design of our methods with a simple heuristic: separating how we get the data from what we do with it.

6.2 Methods, Functions, and Determinism

6.2.1 How do we write functions in Java?

6.2.2 The effect of deterministic functions on reasoning

6.2.3 Functions let you work locally

6.2.4 Functions are tables of immutable data in disguise

6.2.5 Functions let us model relationships

6.2.6 One last note on all this deterministic business

6.3 Organizing the code around determinism

6.4 Implementing the deterministic core

6.4.1 Implementing collectPastDue

6.4.2 Implementing BuildDraft

6.4.3 That really gross wrong feeling is a feature

6.4.4 Implementing Assess Draft

6.4.5 Dealing with optional

6.4.6 It’s always OK to introduce more types!

6.4.7 Adding Support for updating LateFees

6.5 Implementing the non-deterministic shell

6.5.1 Who owns the save logic?

6.5.2 Your Entities are my Data Transfer Objects (DTOs)

6.6 Data is the ultimate interface

6.7 Putting it all together

6.8 Wrapping up

6.9 Summary