Introduction to a development approach for complex domains

1. Intro to
Domain Driven
Design
Tackling Complexity in the Heart of Software
“Eric Evans' 2003 book is an essential read for serious software developers” -- Fowler
There are shorter book versions: “distilled”, “quickly”, “kompakt”, “implementing”, “easily”

2. WIIFM
● Get to know a development approach for complex domains
● Closer internal stakeholder collaboration
● Better architecture (loosely-coupled, cohesive)
○ Easier to change
○ Safer to change - less incidents due to inter-team misalignments
● Companies that exercise DDD were more successful for a long time
● Can be the basis of future breaking of a monolith
● Additional paths of refactoring, not only technical
Images from the DDD book and Martin Fowler’s website

3. Model
“All models are wrong, but some models are useful” -- George Box

4. Ubiquitous Language
● Have the same terminology: developers, POs, analysts, BI, CS, Designers, QAs
● In all deliverables: code, documentation, test cases, business cases, sales
● How? Requirements, talk to domain experts, capture business processes (e.g. event
storming), produce UML, data flow, use industry standards (a.k.a Published Language)
● Examples: User, Airport, Hotel, Hotel room booked

5. Isolating the domain in the code
Layered Architecture
● UI / API - expose data, receive commands
● Application - thin, delegates to domain objects
● Domain - business concepts and rules
● Infrastructure - generic technical capabilities
(email, messaging)

6. Building Blocks
● Entity
○ Has identity, is persisted, is mutable
○ Examples: marked bills, hotel
● Value Object
○ Defined by its attributes, is immutable, depends on Entity
○ Example: unmarked bills, company address
● Aggregate - group of entities and value objects.
○ Example: Purchase (the root), invoice, transactions
● Service
○ Domain business process, has no state
○ Example: book a room
● Factory
○ A common design pattern for encapsulating the building (non-trivial) objects
○ Example: Computer object

7. Storing and retrieving (working with database)
● Repository (aggregates persistence)
A common persistence design pattern (in contrast to Rails’ ActiveRecord)
○ Retrieve collections and associations
■ Example: retrieve all applications with status “pending” and their associated recruiters
○ Store “unit of work”
■ Example: store a purchase with its invoice and transactions
● ORM (Object/Relational Mapping)
○ Map between in-memory objects and the database
○ Reduce cognitive load

8. Building Blocks Summary

9. Bounded Context
A “group” of related models and services with explicit interrelations, e.g. Sales and Support
Note that “Customer” exists in both contexts, but might be different models with translation.
Context Map - identify relationships between bounded contexts

10. Inter-Team relationships
● Shared kernel
● Customer-supplier
● Conformist
● Separate ways
● Anticorruption layer
Conway’s Law: Any organization that designs a system, will produce a design whose structure is a copy of the organization's communication
structure

11. Supple design - technical aspect to make constant changes easier

12. Distillation - defining subdomains
● Core Domain
○ e.g. Performance Marketing on job boards
● Generic Subdomain
○ e.g. User mgmt and permissions
● Supporting Subdomain
○ e.g. Job lifecycle management
● Segregated core
○ To refine a complex core domain

13. Additional terminology
● Domain Events
○ Important events for domain experts (in code or not, inside bounded context or between)
● Event driven (architecture)
○ Components react to events emitted to a messaging solution
● Event sourcing (architecture)
○ Event driven where only events are stored, not current states
● Services / Microservices (architecture)
○ Can compose a bounded context, also third party services
● Design patterns
○ Examples: Anti corruption layer, composition, abstract factory, factory method, strategy,
adapter
● CQRS
○ Objects that read are not the objects that write

14. Continuous refinement of the models
● Domain experts
● Knowledge crunching
● Continuous learning
● Refactoring

15. Common Anti-patterns
● Implicit communications between cores/bounded contexts thru database
● Coupling unrelated objects / decoupling related objects
● Hidden business rules (Utils, small methods)
● Business logic in wrong layers: UI / Controller / DB

16. Within Ruby and Rails Ecosystem
● Ruby Modules ✅
● MVC ✅
● Thin controllers, service objects ✅
● ActiveRecord X (but can build repositories that call ActiveRecord scopes)
● ORM ✅
● CI ✅
● Automated tests ✅
● Refactoring ✅
● Messaging solutions ✅

17. How to start?
● Read the book
● Give an internal tech talk
● Discuss with team members, other teams, stakeholders
● Talk to domain experts
● Have event storming
● Identify one bounded context, refactor into namespaces
● Limit direct communication to/from this bounded context
● Refactor from domain perspective, not only technical

18. How to start?
● Elevate domain concepts and create explicit policy objects (e.g. VAT)
● Move logic only into domain objects
● In architecture evolution, keep DDD in mind

19. Resources
● The DDD book
● Eric Evans Talk
● Object Oriented Software Construction - Bertrand Meyer
● Working Effectively with Legacy Code - Robert C. Martin
● Design Patterns. Elements of Reusable Object-Oriented
Software - Erich Gamma
● https://github.com/ddd-crew/ddd-starter-modelling-process
● CQRS