Finding The Sweet Spot

Transcript

1. Community Partners

2. 12 August 2017 | Andrew Best

3. 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

4. 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

5. “ Object/relational mapping is the Vietnam of Computer Science Ted

   Neward http://blogs.tedneward.com/post/the-vietnam-of-computer-science/

6. The Codes, Part One: Death to the Repository!

7. CQRS >Event Sourcing >Eventual Consistency >Asynchronous Messaging >Separate Persistence Mechanisms

   August 17

8. CQRS >Using separate conceptual models to read and write information.

   >fin August 17

9. The Codes, Part Two: The Sweet Spot

10. 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

11. DDD >No longer have composite UI/other concerns polluting our domain

    >Disconnects our domain model >Can better enforce consistency boundaries >Further reading: http://dddcommunity.org/library/verno n_2011/ August 17

12. 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

13. The Codes, Part Three:

14. Thank You! @_AndrewB https://github.com/andrewabest

15. None