A practical view of Domain Driven Design Introduction

A practical view of Domain Driven Design

Introduction � Who am I? � What is domain driven design? ◦ Approach to developing software by deeply connecting implementation to an evolving model ◦ Focuses on core domain ◦ Bases complex designs on a model ◦ Depends on creative collaboration between technical and domain experts � The book - Domain Driven Design (Eric Evans) � Other resources – Karl Seguin, Jak Charlton

Knowledge Crunching � Detailed dialog with domain experts � Whiteboard sessions � May require domain knowledge ramp up via documentation reading � Even third party help � Prototype � Get early draft version of model – refine to deeper model over time

Ubiquitous Language � What is UL? � The whole team must buy into UL � Continuously refactored � Output of knowledge crunching � Glossary

Entities � Integral concept of the ubiquitous language � Unique Identifier � Should encapsulate behaviour, avoid the anaemic model (where possible) � By default are not immutable ◦ But can be immutable � Should never be left enter an invalid state

Value Objects � Do not have identity � Immutable � Should implement an equals method � Cannot exist by themselves in the model 02/01/2022

Aggregates � Contains a root entity � Root entity responsible for checking invariants � Only root entity can be referenced from outside aggregate boundary 02/01/2022

Domain Services � Some logic doesn’t fit in entities/value types � A service is an operation offered as an interface that stands alone in the model, without encapsulating state, as entities and value objects do � Should be stateless

Modules � Almost all software projects have modules � Can be achieved by: ◦ Different namespaces ◦ Different assemblies

Bounded Contexts � Explicitly defines a context in which a model applies � Gives clarity (eradicates ambiguity) for team � Context map

Factories/Repositories � Work with aggregates � Factories are responsible for building aggregates � Repositories are responsible for persistence operations on aggregates ◦ Factory example ◦ Persistence ignorance example

Deep Models/Supple Design � Making ◦ ◦ implicit concepts explicit Breakthroughs Specification Pattern Compose Method New class � Intention revealing interfaces � Side-effect free functions � Assertions

Maintaining Model Integrity � Conformist � Anticorruption layer ◦ Really applies when integrating to external subsystems � Separate ways � Publish the language ◦ Diagrams ◦ API documentation

Distillation � Core domain � Generic subdomains � Highlighted Core � Segregated Core � Eliminate noise

Command Query Separation � For us, it simply has meant don’t mix reporting concerns in the domain � CQRS – Command Query Responsibility Segregation ◦ Greg Young ◦ CQS at an architectural level

Other stuff � Prototypes � Simulators � Continuous Integration � Automated Testing � IOC

Conclusion � Only apply DDD to complex codebases � Consider core DDD concepts mandatory � Twitt: @bstack � Email: bs. stack@gmail. com