Domain Driven Design At it’s heart, DDD is about TAMING COMPLEXITY It allows us to reason about the software we are building, explicitly modelling our problem domain in unambiguous terms and supplying well-defined semantics for its concepts. August 17 2
Meet the > Our domain model facilitates the real-world process requirements from our problem domain – This is what it should be doing > Our applications’ demands on their persisted state extend beyond our domain model – Task-based UIs, Reporting, Exporting, etc. > Often the domain model becomes the single façade over our persistence layer – it is set to work servicing these additional demands as well > It then becomes MORE COMPLEX > It then becomes HARDER TO REASON ABOUT > And then you add an ORM August 17
CQRS >Read and write concerns truly separated >Can co-evolve without side effects >Minimal additional complexity >Use the best tool for the job August 17
Abstraction >Removed the potential foot- gun of complex EF queries >Humans struggle with DSLs >Can write tailored, specific queries that suit individual demands >But what about that type safety we just gave up? >Well… August 17