Skip to Content

Book: Domain modelling made functional

tags
Functional Programming
  • DDD is particularly useful for business software

    • Especially when interfacing with non-technical teams
  • The person who produces the design should be intimate with the domain they’re working in

    • This removes all middleman between the domain expert and the developer
    • Furthremore, the design should be accessible to everyone involved in development of the software
  • Steps to DDD

    • Collect as much fine-grained information about business workflows and events
    • Resist designing till all information is gathered
    • After collecting workflows and events, then break them into subdomains
      • Subdomains should be autonomous
    • Next, create bounded contexts from each subdomain.
      • A bounded context could contain multiple public and internal workflows
    • Next, create contracts between each of the bounded contexts
      • Between bounded contexts, they should interact using Domain Transfer Objects (DTOs)
      • DTOs are meant to be serialized and deserialized between bounded contexts.
    • Within the boundaries of the bounded context, it should deal only with domain objects
  • Layers of the boundary of a bounded context from outermost to innermost

    • Serialization/Deserialization: Converts DTOs to domain objects
    • Input/Output gates:
      • Input gate: Does input validation according to constraints
      • Output gate: Removes extra fields from the output to adhere to contract and prevent accidental coupling
    • ACL: Anti-corruption layer. Converts the incoming domain to the domain needed by the current bounded context
  • Layers of a bounded context from inntermost to outermost:

    • Domain: Handles domain logic and constraints
    • Services: Interactions between the domain and the IO layers
    • I/O: Everything dealing with input/output i.e. Databases, Network, Files etc
  • A bounded context can contain multiple workflows that cut across all it’s layers

  • Values: Data without a persistent identity

    • When a component of a value changes, it changes.
    • Thus it can be compared using the equality operator
  • Entities: Data with a persistent identity through time

    • An entity does not change as its components change
    • It needs a top level identifier field to compare for equality
      • This allows us to work with immutable identities
  • Aggregate: A collection of entities which change together.

    • Used to enforce consistency and invariants.
      • Ex: When X component changes, Y component should change too.
    • Only store those entities in an aggregate that change with the aggregate
      • For others store identifiers as reference
    • Aggregates are the atomic units of persistence, transactions, and data transfer
    • Any updates to its components should be done at the top level of the aggregate.
  • When modeling domains, use Vales, Entities, and Aggregates to capture the domain in types

    • Use Undefined as a placeholder type to be unblocked and proceed with the process