This document discusses designing domain-driven microservices using CQRS patterns. It recommends modeling microservices around bounded contexts and aligning code to business problems. While DDD is useful for complex services, simpler architectures may suffice for CRUD services. The document also describes how to implement CQRS by separating read and write models, using commands for writes and queries for reads. This improves performance, scalability and permission management. The example architecture shows a gateway routing requests, with separate persistence and querying servers each making single database calls to minimize response times.

1. 2
DDD & CQRS For
.NET Developers
Allan Spartacus Mangune
Softcon 2019
2

2. Application
Database
Logs
Messaging
Queuing
Authentication
Pull all data for pagination
No filtering of data
3

3. 4

4. 0
25
50
75
100
125
July 1 July 2 July 3 july 4
5
80 vCores of CPU

5. 6
Monolith
App1
Identity Server
App2
App3
Logs
File ProcessorMessages
/Notification

6. Design Objectives
• Read API calls must return in less than a second
• Less memory footprint of objects
• Simple architecture
7

7. Read API calls must return in
less than a second
• Cache the database rather than employing a separate
caching solution
• Data retrieval must be done in one database call
• Even if we are retrieving data from more than 5 tables
8

8. Less memory footprint
• Avoid instantiating many objects
• Avoid subclassing
• Use static methods when applicable
9

9. Simple architecture
• Avoid unnecessary methods calls introduced by over-
architecture
• Don’t be afraid to employ hybrid solutions based on know
software architecture
10

10. Designing a Domain-
Driven Design (DDD)
Microservice
11

11. Designing Microservices
• Model microservice based on Bounded Context
• A Bounded Context simply means a group of
functionalities of a single business operation
• Use ubiquitous terms to organize code.
• Align code to business problems
12

12. Should we always use DDD?
• DDD is helpful when building complex micro services with
significant business rules
• When most services are simply CRUD, use simple
architecture
13

13. Application
Database
Logs
Messaging
Queuing
Authentication
Pull all data for pagination
No filtering of data
14

14. Designing & refining micro services
means drawing boundaries among
business processes
15

15. Application
Database
Logs
Messaging
Queuing
Authentication
Pull all data for pagination
No filtering of data
16

16. We should keep micro
services context boundary
small
17

17. 18
Monolith
App1
Identity Server
App2
App3
Logs
File ProcessorMessages
/Notification
• Decompose to small
microservices
• Merge
microservices that
need to collaborate
a lot

18. Layering
19

19. If you expect that your code base
would eventually become complex,
separate logically your code
20

20. 21
Application Layer
• API
• API contracts
• Commands
• Queries
Domain Model Layer
• Domain entity model
• Plain old C# objects
Infrastructure Layer
• Data Persistence
• ORM, Entity Framework
• Logging
• File Processing

21. 22
Monolith
App1
Identity Server
App2
App3
Logs
File ProcessorMessages
/Notification
• Gateway
• Persistence and
• Querying Servers

22. 23
App1
• Gateway
• Persistence and
• Querying Servers
Gateway
Persistence Server
Querying Server

23. Command & Query
Segregation Responsibility
(CQRS)
24

24. CQRS
• Segregates the write operations from read operations
• Maximize performance and scalability
25

25. Application
Database
Logs
Messaging
Queuing
Authentication
Pull all data for pagination
No filtering of data
26

26. Traditional Approach
27
Presentation
Validation
Business Logic
Data Access
Read Write
Storage

27. Problems
• Queries are complex and retrieval of unnecessary data
• Write operations to more than two tables are not secured
by a Transaction
• Managing permissions become complex since the same
entities are used to read and write data
28

28. Solution
• Separate the Models for Read and Write operations
• Commands are used for Write operations
• Task-based like book a room or cancel a flight
• Typically executed as asynchronous operations
• Queries are used for Read operations
• Models are never used for data modification
29

29. Disadvantages
• You might not be able to auto-generate your Read entities
• You might implement having a separate database for
Read operations
• Will add complexities like making data in-sync
30

30. We don’t “overachitect”
31
Database caching

31. We keep things simple
• We borrow the concept of CQRS but never used
Messaging for data syncing
• We use Transactions when modifying related tables from
difference database
• Fast and simple
32

32. 33
App1
• Gateway
• Persistence and
• Querying Servers
Gateway
Persistence Server
Querying Server

33. Gateway
• Pass-through API methods
• Decides which internal app layers will be called
• Returns the DTOs to the calling mobile apps without the
need for additional data parsing
34

34. Persistent Server
• Have endpoints that handle that prepare input data for database Read
operations
• Each endpoint call is passed to a Handler method that communicates
with the database
• Does not return any data written to the database.
• Will only return a scalar value
• Speed is a main requirement so business rules are enforced deep in the
SQL code
• One database call should be enough to complete a database Read
operation
35

35. Querying Server
• Have endpoints for processing Read operations
• Speed is a main requirements so business rules are
enforced deep in the SQL code
• Regardless of the number of tables affected by the query,
only one database call is run against the database
• Returns Data Transfer Objects (DTOs) that don’t
encapsulate any business logic
36

36. Sample Code
37

37. 38
Interface for Method calls
Lightweight Classes
that carry data
Query Data Models

38. 39
Command Data Models
Lightweight class that
carry the data for database
Handler

39. 40
Database Handlers that
talk to the database
Dapper and SqlClient code

40. Summary
• Monolithic App
• Domain Driven Design
• Command and Query Responsibility Separation
41

41. Questions and Answers
• …
42

42. Thank You
43