Domain Driven Design (DDD) Cheat Sheet

  • DDD is an approach to data modeling
  • Separating the quick-changing to ever-stable data
  • 4 Layers
    • Infrastructure Layer = almost never change
    • Domain Layer = hardly change
    • Application Layer = could change frequently
    • Presentation Layer = changes all the time

Layers

  • DDD mostly focus on crafting the domain layer
  • Domain layer encapsulates all the domain logic

Domain vs. Application Layer

  • Domain logic = logical part of the business, i.e. the syntax of the business
  • Application logic = the configurable part of the business, i.e. the semantics of the business
  • The domain model is there to ensure the domain is legitimate, or, is syntactically correct
    • Example 1: When we put some goods to a spot in a warehouse, the spot should be empty; after we put the item in, the spot should be occupied; if someone else try to put another item in the same spot, it should not be denied
    • Example 2: In the domain of car plate registration, the plate number must always be unique, if someone try to register a plate that was already assigned to another car, the system should not allow it
    • Example 3: If I want to buy a ticket, the ticketing system should only issue a ticket after receiving the money
  • Domain logic should look very simple and intuitive and should be the same for most people familiar or unfamiliar with it, because it is based on basic logic that rarely changes
  • It should only cares about syntax but not semantics, as the latter could vary amongst different instances of the domain
    • Syntax error: two car plates had the same number; the balance between two parties in a successful transaction do not equal to zero; a ticket is issues without transaction attached to it; system shows that 100 items are at the exact same spot of a warehouse; price for an item is negative 5 dollars
    • Semantics error: a supermarket casher decide the shutdown the shop for half day; a visitor of a website can view the earnings of the site admin; someone won lottery 5 consecutive times
  • In short, if a syntax error happens, something illogical / unphysical / impossible happens; if a semantics error happens, we may feel strange but still the business plays by rules
  • Another example
    • There is a flight / business trip booking system
    • In Big Company A, only the boss can view where other people are going
    • In Startup B, everyone can see where everyone is going
    • They have very different semantics, people from one company with feel very strange about the other company, but the syntax stays the same
  • As domain logic rarely changes, so when the syntax stays the same, we are in the same domain
  • When the domain logic really change, it is highly possible that we have entered into a completely different domain
  • Each company, organization, application could have different semantics, as how the domain model is manipulated, but the domain model stays the same
  • More examples
    • HR service provides salary reports, one company allows only an employee to see his/her own salary report, another allows the employee and the boss, yet another allows everyone to see everyone; all in the same domain, same business logic, but different semantics
    • A car production line can be stopped by a button, in Toyota, everyone working on the line has the power to push the button, in Ford, only the boss has the authority; same syntax (push button > stop line), different semantics (who can do it)
    • In shop A, when you buy something, you get 1 credit for each dollar you spend, in shop B, you get 100 credit for each dollar you spend; same syntax, different semantics
  • When we have different set of semantics, we basically have a different application
  • That is the core difference between application and domain
  • This makes domain very stable and reusable across applications sharing the same syntax

Other Layers

  • Infrastructure = database, tables, message queues, basic components that could be reused in any domain and any application
  • Presentation = how the data is displayed (presented), like Web page, themes, apps, etc.

Other Ideas

  • Ubiquitous Language = When any members of the domain / on the team say “order”, we want to make sure everyone is referring to the exact same thing, so we clearly define a set of terms and use them throughout our data modeling
  • Bounding Context = There are situations when different players in the same domain must use the same name for slightly different things, then we bound a term to a context
    • For example, when referring to a “customer”, a sales is thinking about the customer’s business problem, revenue, etc.; a technician is thinking about the customer’s architecture, software stack, engineer team structure; a support personnel is thinking about the support plan, last support situation, customer contact name, etc.
    • They all use “customer” and it is difficult to give a different name for each slight variation or perspective they have, so we bound the customer to SalesContext, EngineerContext and SupportContext and create models corresponding to those contexts.