Intro to Domain Driven Design

Intro to Domain Driven Design

• 1.
  Intro to Domain Driven Design TacklingComplexity 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 toknow 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 arewrong, but some models are useful” -- George Box
• 4.
  Ubiquitous Language ● Havethe 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 domainin 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 ● Sharedkernel ● 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 - definingsubdomains ● 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 ● DomainEvents ○ 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 ofthe models ● Domain experts ● Knowledge crunching ● Continuous learning ● Refactoring
• 15.
  Common Anti-patterns ● Implicitcommunications 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 andRails 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 DDDbook ● 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