Keep this open while you read someone else’s code. For each domain object you find, ask “which row does this belong to?” — and if nothing fits cleanly, that’s worth noting rather than forcing.
| Term | One-line meaning | Strongest Java signal | Module |
|---|---|---|---|
| Ubiquitous Language | Shared, precise domain vocabulary used in both conversation and code | Recurring domain nouns/verbs in type and method names | 2 |
| Domain / Subdomain | The problem space and its parts: Core, Supporting, Generic | Clusters of high- vs low-specificity business logic | 3 |
| Bounded Context | A boundary within which one model and one language hold consistently | Module/package/service boundary; the same name with different shapes on either side | 4 |
| Context Map | The relationships — technical and political — between Bounded Contexts | Shared modules, translator/adapter classes, cross-service clients | 5 |
| Entity | A domain object with continuous identity, mutable over its lifecycle | An id field plus id-based equals(); @Id |
6 |
| Value Object | Defined entirely by its attributes, immutable, no identity | A record; final fields; all-field equals(); @Embeddable |
6 |
| Aggregate | A consistency-bounded cluster of Entities and Value Objects, accessed via one root | A root Entity owning children that have no Repository of their own | 7 |
| Aggregate Root | The single Entity that’s the entry point to an Aggregate | The Entity type that actually has a Repository | 7 |
| Repository | Collection-like access to whole Aggregate Roots | *Repository interface, often a Spring Data extends JpaRepository<Root, Id> |
7 |
| Domain Service | Stateless domain logic that spans more than one Entity or Value Object | A stateless class, named for a verb, containing an actual business rule | 8 |
| Domain Event | An immutable, past-tense fact that domain experts care about | A past-tense record published through an event mechanism, with listeners on the other side |
8 |
| Factory | Encapsulated, invariant-safe construction of a complex object | A static factory method (Order.place(...)), a dedicated *Factory, or a validating builder |
8 |
| Module | A domain-named package that groups related concepts | Packages named after the domain (...sales.order), not the architecture (...dao) |
8 |
| Application Service | Orchestration only — transactions, security, calling repositories — never business rules | A *Service class coordinating calls, containing no domain logic itself |
8 |
The nine Context Map relationships
A condensed version of the Context Mapping module — useful as a checklist when you’re working out how two Bounded Contexts actually relate.
| Pattern | In one line |
|---|---|
| Partnership | Two contexts succeed or fail together; coordinated, mutual dependency |
| Shared Kernel | A common subset of the model, shared deliberately, changed only by agreement |
| Customer–Supplier | Upstream supplies downstream; downstream’s needs are negotiated upstream |
| Conformist | Downstream adopts the upstream model wholesale, with no translation |
| Anticorruption Layer | Downstream translates the upstream model into its own terms at the boundary |
| Open Host Service | Upstream publishes one well-defined protocol for many downstream consumers |
| Published Language | A shared, documented interchange format — often what an Open Host Service exposes |
| Separate Ways | No integration at all, by deliberate choice |
| Big Ball of Mud | No clear boundary, no consistent model — name it rather than pretend otherwise |
Tip. When two patterns both seem to fit, the deciding question is usually political, not technical: can the downstream team actually get a change made upstream? If yes, Customer–Supplier. If no, Conformist or an Anticorruption Layer, depending on whether they translate or just absorb.