B 211 DomainDriven Design Patterns in NET http

B 211 : : Domain-Driven Design Patterns in. NET http: //naa 4 e. codeplex. com @despos @andysal 74 http: //facebook. com/naa 4 e

(R) A single model caring about all aspects of the domain is hard. Command/Query Separation (cit. Bertrand Meyer – 1980 s) Command Query > Alter state > Doesn’t return data > Returns data > Doesn’t alter state

CQRS Domain Model Presentation layer Application layer Domain layer Infrastructure layer Commands Queries

§ We faced a lot of complexity in modeling § We thought it was inherent domain complexity § That more likely resulted from the Cartesian product of queries and commands O(C x Q) vs. O(C + Q)

§ Regular • Transaction Script in the Command stack • Query stack (LET or SQL) § Premium • Domain Model in the Command stack • Ad-hoc read model § Deluxe • Domain Model and events (sourcing) in the Command stack • Ad-hoc read model (with snapshots) …

Regular § Transaction Script • • Task-based, end-to-end use-case implementation One core “transactional” method per user action Not strictly model based, “it-just-works” approach Money-back guarantee! § Two-layer query stack • Just queries: LINQ-to-Entities, ADO. NET • No models; just DTOs Why making your life harder than it actually is?

§ § Layered Expression Trees It’s an idiom Make queries speak the ubiquitous language Composition of IQueryable extension methods • IQueryable up to the application layer § DSL-like expressivity

How to use ubiquitous language while querying Database unit s s e n i s u b As a lect l o c o t t n a w manager, I oing g t u o l l a r o credits f id a p n u l l i t s invoices . Issued. Invoices. Per. Business. Unit(business. Unit. Id). Unpaid(). Select(i => new { Invoice. Number = i. Number, Customer. Id = i. Customer. Id });

Premium § Domain Model in the Command stack • Domain Model focused on behavior that alters state C § Ad-hoc storage for queries in the Query stack • Table-per-view strategy • Query through LET Q

Deluxe § Domain Model in the Command stack • Domain Model focused on behavior that alters system ‘s state • Events in the building of tasks • Optionally, events as the primary data source § Ad-hoc storage for queries in the Query stack • Table-per-view strategy • Query through LET • Data snapshots and replay of events

Application sends a command to the system 1. Command takes effect 2. System’s state changes 3. Changes notified through events to registered subscribers (aka, handlers) • Workflow managers (aka, sagas) • Denormalizers (used to generate ad-hoc views) Typically: events are notified and commands executed via a mediator (aka, bus)

http: //naa 4 e. codeplex. com

Domain Layer Application Layer Handlers Read stack

SQL XXX • Everyone’s skills • Ecosystem of tools • On-Premise & cloud MSMQ • Lots of code Mongo. DB • • Free Linux and Windows On-Premise & cloud Schemaless NEvent. Store Raven. DB • • LINQ support TX+DTC support Schemaless On-Premise & cloud NService. Bus • Free • Advanced config • FOSS • Advanced features • DDD/CQRS/ES full stack

B 211 : : Domain-Driven Design Patterns in. NET http: //naa 4 e. codeplex. com @despos @andysal 74 http: //facebook. com/naa 4 e

http: //www. visualstudio. com http: //blogs. msdn. com/b/developer-tools/ http: //msdn. microsoft. com/vstudio

http: //channel 9. msdn. com/Events/Tech. Ed www. microsoft. com/learning http: //microsoft. com/technet http: //developer. microsoft. com