This chapter looks into how we can model business processes with code, in a way
that’s highly compatible with TDD. We’ll discuss why domain modeling
matters, and we’ll look at a few key patterns for modeling domains: Entity,
Value Object, and Domain Service.
Figure 1-1 is a simple visual placeholder for our Domain
Model pattern. We’ll fill in some details in this chapter, and as we move on to
other chapters, we’ll build things around the domain model, but you should
always be able to find these little shapes at the core.
Figure 1-1. A placeholder illustration of our domain model
What Is a Domain Model?
In the introduction, we used the term business logic layer to describe the
central layer of a three-layered architecture. For the rest of the book, we’re
going to use the term domain model instead. This is a term from the DDD
community that does a better job of capturing our intended meaning (see the
next sidebar for more on DDD).
The domain is a fancy way of saying the problem you’re trying to solve. Your
authors currently work for an online retailer of furniture. Depending on which system you’re talking about, the domain might be purchasing and procurement, or product design, or logistics and delivery. Most programmers spend their days trying to improve or automate business processes; the domain is the set of activities that those processes support. ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month, and much more.
