Should CQRS cross many BCs?

163 views
Skip to first unread message

Caspar

unread,
Jan 2, 2021, 10:08:42 AM1/2/21
to DDD/CQRS
Martin Fowler tells,  " In particular CQRS should only be used on specific portions of a system (a BoundedContext in DDD lingo) and not the system as a whole. In this way of thinking, each Bounded Context needs its own decisions on how it should be modeled.  "


It's an example here.

Either Order or Product is aggregate root in its BC. Someone wanna to place an order. So the system do these steps: 
  1. Service sends a query to ProductRepository to get the list of all products, and returns the list to UI.
  2.  Customer chooses products from the list, and submits them.
  3.  Service sends command AddItems to Order. All details of picked products are included in the command AddItems.
  4.  Order handles the command AddItems, adds some OrderItem, and pushes event ItemsAdded at last.
  5.  Service subscribes event ItemsAdded, so it rewards the event to UI to update the display of order details.
My question is:
  1. Is the ProductRespository part of read model of Product BC?   
  2. Is the Order part of write model of Order BC?
  3. The service crosses the Product BC and Order BC. Does it means that CQRS pattern crosses two BCs?
Thanks.

Brandon Piner

unread,
Jan 2, 2021, 11:52:54 AM1/2/21
to ddd...@googlegroups.com

Its worth giving his BC article a thorough read https://martinfowler.com/bliki/BoundedContext.html
A key takeaway is quoted below:
"Bounded Contexts have both unrelated concepts (such as a support ticket only existing in a customer support context) but also share concepts (such as products and customers) " 

Bounded contexts are just boundaries for the "Ubiquitous Language" that will be used
 
Is the ProductRespository part of read model of Product BC?   
The Product read model would fall within the product BC because it uses terminology specific to Product

Is the Order part of write model of Order BC?
Same as above. The write model will use terminology specific to the Order BC so it will fall within the Order BC.

The service crosses the Product BC and Order BC. Does it means that CQRS pattern crosses two BCs?
(Assuming "service" means "microservice") 
A guideline is that a service could be as small as one aggregate root to as big as one bounded context. 
If the Order and Product aggregate roots are part of the same BC then they can be within the same service.

There is also nothing stopping aggregate roots from different BCs referencing each other. As long as the reference is by ID. 
An Invoice aggregate root can keep product IDs of all the products that are on the invoice. But it should not keep a copy of the product.


--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dddcqrs/25686251-4a75-4ded-aa41-bc6509e41f95n%40googlegroups.com.

Chris Richardson

unread,
Jan 2, 2021, 12:04:42 PM1/2/21
to ddd...@googlegroups.com
Caspar,

Why do you want to use CQRS?
What specific problem does it solve?

Chris

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dddcqrs/25686251-4a75-4ded-aa41-bc6509e41f95n%40googlegroups.com.


--
Learn microservices - http://learn.microservices.io
Microservices application platform http://eventuate.io
Consulting and training http://chrisrichardson.net

Caspar

unread,
Jan 3, 2021, 2:39:01 AM1/3/21
to DDD/CQRS
It's a backend of an App about restaurant. Most of the time, customers should not place order finally, but view the details of dishes. The load of handling query is more than handling command. So I want to split queries and commands into two models with CQRS pattern, and optimize the read model as much. 
Reply all
Reply to author
Forward
0 new messages