Domain Driven Design (DDD) is an approach to software development that centers the design around the core domain or business logic. It advocates for close collaboration between technical and domain experts to build a ubiquitous language within bounded contexts. The key aspects of DDD include isolating domain models and business rules within entities, value objects, aggregates, and services layered according to business needs rather than technical constraints. Continuous refinement of models through collaboration ensures the design effectively captures the domain as business needs evolve. DDD provides principles for breaking large monoliths into loosely coupled services and microservices to support flexible design and development.

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