It’s more of a scenario, but it isn’t far fetched at all. Let’s say I have an Aggregate Root (AR) Warehouse which it’s used to manage product stock. The Product itself is an AR in a different bounded context (BC) but in this BC is represented only by an id. In the Warehouse I can add a new product (must be unique), Ican remove it and i can update stock. Of course, I can communicate the stock for a product and maybe even keep the in/out flow for a product.
THe problem is you can easily reach hundreds or thousands of products. So, for any wareohuse action you’ll have to load everything even if that action won’t use all that info. It’s highly inefficient.
A solution I could think of is to pretty much ‘break’ the warehouse AR in specialiazed objects for different actions. But this means we no longer have an AR and we’re back to a CRUD like solution. Even more so, the AR was split not becasue the Domain need it, but because the technical details need it.
It looks like you can do DDD until a certain point, after that you go CRUD or buy a MUCH BIGGER and expensive server.
What do you think? Can we have both DDD and efficiency when lots of data is involved?
Can we have both DDD and efficiency when lots of data is involved?
Yes, however DDD is not entirely free of technical constraints, especially in more modern architectures. An aggregate can be thought of as a transactional consistency boundary and not simply a pure representation of the business domain. When thinking of an aggregate as a consistency boundary it can be designed in a way that optimizes corresponding use cases.
In your scenario, having a large Warehouse aggregate will result in overlapping boundaries – the stock information of one product has no integrity constraints associated with other products. The problem may be that the Warehouse aggregate contains behavior for managing stock in addition to serving as a sort of anchor for your domain model. One solution would be to shift behavior to a ProductInventoryAggregate. Another could be to introduce eventual consistency.
Take a look at Effective Aggregate Design by Vaughn Vernon for more on this. Overall however, I do see the tension your observe between focusing on the pure domain on the one hand, but considering technical constraints on the other. This isn’t too much of a conflict, for me at least, since I view the central value of DDD as being the strategic patterns not tactical ones.