Introduction

We’ve found that many developers, when asked to design a new system, will immediately start to build a database schema, with the object model treated as an afterthought. This is where it all starts to go wrong. Instead, behavior should come first and drive our storage requirements. After all, our customers don’t care about the data model. They care about what the system does; otherwise they’d just use a spreadsheet.

The first part of the book looks at how to build a rich object model through TDD (in [chapter_01_domain_model|chapter_01_domain_model]), and then we’ll show how to keep that model decoupled from technical concerns. We show how to build persistence-ignorant code and how to create stable APIs around our domain so that we can refactor aggressively.

To do that, we present four key design patterns:

• The Repository pattern, an abstraction over the idea of persistent storage
• The Service Layer pattern to clearly define where our use cases begin and end
• The Unit of Work pattern to provide atomic operations
• The Aggregate pattern to enforce the integrity of our data

Three layered architecture

Chapter 1. Domain Modeling

• The problem we are trying to solve as a software engineer is called as Domain.
• For an online retailer of furniture, 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.
• A model is a map of a process or phenomenon that captures a useful property.
• The domain model is the mental map that business owners have of their businesses. All business people have these mental maps—they’re how humans think about complex processes.