Skip to content
academia.sh
tr
Log in

Course Advanced

Domain-Driven Design

By the end of this course

Start course

01

The Domain Model

Aligning complexity with the domain: merging code and spoken language into a single vocabulary, separating objects defined by identity from immutable objects defined by value, drawing the consistency boundary with aggregates and the root, giving behavior that does not belong to an object to domain services, fitting creation and access to the domain model, an explicit model of meaningful business events, and the cost of behaviorless data classes.

  1. 01 Rationale for Domain-Driven Design Turning the model's alignment with the domain into a measure: counting how many of the twelve names in the domain expert's single sentence are found verbatim in two models, measuring how many candidate lines three change requests phrased in domain language reduce to in each model, and showing that two models produce the same fee — establishing that alignment is a quality distinct from correctness.
  2. 02 Ubiquitous Language Merging code and spoken language into a single vocabulary: counting the number of names per domain concept across two versions, measuring the number of translation points and unit conversions between two names for the same concept, working out how many bodies the same rule is written in and how many of them apply the cap, and measuring how often the quote and the fee diverge across thirty shipments.
  3. 03 Entities The selection criterion for objects defined by identity: counting how many separate instances twelve shipments reduce to under value equality, measuring how many invoice reads come out correct, working out how many keys point to the same identity after a reweighing correction, and comparing what the two equality definitions answer to the domain's two questions.
  4. 04 Value Objects The selection criterion for immutable objects defined by value: counting how many wrong amounts the bare-number model produces from twelve inputs arriving in grams, measuring how many lines the equality rule is written by hand, working out how many shipments break when a shared measurement is corrected in place, and showing that the two models produce the same grouping.
  5. 05 Aggregates and the Root Drawing the consistency boundary: counting, across five paths, how many separate call paths can break the discount-cap invariant, showing that this count drops to zero when access passes through the root, measuring how many aggregates a single transaction touches, and the cost of turning the link between aggregates into an identity reference.
  6. 06 Domain Services Measuring, across two models where best-tariff selection is loaded onto the shipment and where it is handed to a separate domain service, the number of modules the shipment module imports, the number of objects reachable from a shipment, and the serialization length; counting the persistence trace that separates the domain service from the application service.
  7. 07 Factories and Repositories Fitting creation and access to the domain model: counting how many of an invalid shipment's four creation paths can produce it, this count dropping to zero in the model that passes through a factory, measuring the column name, operator, and threshold count that leaks into the call site when the repository interface is written in the query language, and showing that the two repositories give the same result.
  8. 08 Domain Events The explicit model of meaningful business events: measuring, across two logs produced from the same sixty facts, how many of the domain expert's three questions are answered correctly with a single filter, counting how many events' fields have to be compared for the answer, and comparing the rate at which event names are found in the domain vocabulary and the log length.
  9. 09 Anemic Domain Model Critique Measuring behaviorless data classes in the context of the domain model: counting how many separate services the same five rules are written in and how many file edits the five rules require, counting how many times, across 36 shipments, services writing the same rule give a different result, and comparing how many of the domain expert's verbs can be asked of the shipment.

02

Bounded Contexts

Drawing the boundary of the area where a model holds and mapping the relationships between contexts: one word naming two different objects in two contexts, the relationship types on the context map, stopping the outside model's leakage with an anti-corruption layer, the shared kernel and conformist collaboration patterns, and separating core, supporting, and generic subdomains.

  1. 01 Bounded Context The boundary of the area where a model holds: counting the fields a class carries and the field pairs that never appear together in any use case when one word's two meanings are combined into a single class, measuring how many objects two contexts' invariants reject when merged into that class, and showing that drawing the boundary does not change the fee.
  2. 02 Context Map Relationship types between contexts: separating the upstream and downstream direction, extracting the map from real imports, counting the mutually dependent context pair and the number of contexts affected when one context changes across two maps, and measuring how many core files the upstream's names appear in.
  3. 03 Anti-Corruption Layer Preventing the outside model from leaking in: counting how many files two carrier providers' names, state sets, and units appear in, measuring the number of external state values the business rule recognizes, showing that leakage in the core files drops to zero once a translation layer is added, and working out the layer's cost in files and lines.
  4. 04 Shared Kernel and Conformist Two collaboration patterns: counting the rate of changes requiring a joint decision and the number of files two teams edit together as a shared kernel grows, measuring the core files used by a single context, and comparing the conformist arrangement's file and line savings against the number of names left in downstream's own vocabulary.
  5. 05 Subdomains Separating core, supporting, and generic subdomains: establishing the difference between a subdomain and the domain layer, deriving the effort share per subdomain from line and invariant counts, computing the change share from the change log, and measuring how effort and change align once the generic subdomain is thinned.

03

Connecting to the Application Architecture

Placing the domain model inside an application: defining the application layer's responsibility through use cases, separating the domain's outward connection points with adapters, the cost and gain of separating the write and read models, storing the event sequence instead of state, and the model's evolution together with the implementation.

  1. 01 Use Cases Defining the application layer's responsibility through the use case: counting decision points across two versions of the same scenario — one that carries decisions in the application layer and one that pushes them down to the aggregate root — measuring how many places the domain expert's five sentences are written in the code, and testing the two versions' behavioral equality.
  2. 02 Ports and Adapters Presenting hexagonal architecture as an arrangement: turning the places the domain opens to the outside into named ports, counting the domain module's import closure and its direct links to the outside world across two arrangements, running the same domain file with two adapter teams, and reporting an unsatisfied port at run time.
  3. 03 Command and Query Responsibility Segregation Separating the write and read models: producing the operation dashboard from the aggregate roots and from a separate read model, comparing the number of objects visited across three data sizes, measuring how many commands behind the read model falls and how many answers come out stale, and the cost in added files, lines, and mapping writes.
  4. 04 Event Sourcing Storing the event sequence instead of state: comparing how many of four questions the state table and the event sequence can answer, counting how many events are read to rebuild state from events, measuring how the number of events read and snapshots written changes as the snapshot interval changes, and comparing the byte size of the two persistence forms.
  5. 05 Model-Driven Design The model's evolution together with the implementation: counting how many of the seven names in the domain expert's sentence are found in the model's vocabulary, measuring the drop in parallel-array indexing and rule writing sites once the implicit route-leg concept is exposed, the improvement's line cost, and testing the behavioral equality of three reports.

Start typing to search.

↑↓ ↵ Esc navigate · open · close