DDD, Microservices, Aggregates and DCI
Unmesh Joshi
Matthew Browne
Hi Unmesh,
On the surface, aggregates seem like a good way of decomposing
microservices, and if you had asked this question two years ago I
would probably have said this makes perfect sense, but since then
I have learned about a different architectural approach that I
think is a much better fit for microservices: volatility-based
decomposition.
I would say that volatility-based decomposition tends to look
closer to functional (use case-based) decomposition than domain
decomposition, but it really depends on how you anticipate the
parts of your system to change over time, so it could
coincidentally look similar to either of the above two approaches
depending on the particular services and their rates of change.
(There are also cross-cutting concerns like utilities/helpers that
often make sense as independent, shared services.) Here is a great
video that explains the concept—it's long, but contains a lot of
good info:
https://www.youtube.com/watch?v=VIC7QW62-Tw
There is a major parallel to DCI here: within a DCI application, the data model is separated from the use cases in the source code in large part because the use cases have much higher volatility than the relatively-stable structure of the data model (Jim Coplien talks about this often). To be clear, I'm not suggesting to apply the same data/domain vs. functionality separation to microservices, but rather to apply the underlying principle.
The rest of this email contains some further advice that is mostly inspired by the lead architect at my company, who introduced me to volatility-based decomposition and whom I consider an expert on microservices...
Here is an example of what not to do:
https://segment.com/blog/goodbye-microservices/
They originally had over 140 very fine-grained microservices with all kinds of tricky interdependencies. The article concludes by saying they're better off now with more of a monolith approach, but unfortunately it seems they now have just swung to the other extreme. Service decomposition is still very valuable, but has to be done at the right level to be effective.
Early OO thinkers were enamored of the concept of emergent behavior: create a bunch of smart objects, let them interact with each other, and you'll have a great system whose intelligence far surpasses the some of its parts. Unfortunately, while perhaps that might work for certain simulations of natural phenomena, it doesn't work well at all for business software—you need to explicitly create structure and design how the components of your system will interact. Recently there has been interest in applying the actor model to microservices, which certainly has potential, but only if done at an appropriate granularity and carefully considering how the services will need to interact. DDD aggregates are one way to provide structure, but you definitely want to avoid things like having to join tons of data in memory (think database join) for some important use case that depends on data from two or more aggregates.
One more thing about volatility-based decomposition: as with many
things, it's based on theory that has been around for a long time.
Although I haven't personally read it (it's on my reading list
though), here's a paper my boss recommended:
https://prl.ccs.neu.edu/img/p-tr-1971.pdf.
P.S. Microservices bring to mind SOA. I'm not sure how relevant
this is here, but here is a past thread where some parallels and
differences between DCI and SOA were discussed:
https://groups.google.com/d/msg/object-composition/e6K7KhKkdnM/SIC76rXUxbMJ
--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.
To post to this group, send email to object-co...@googlegroups.com.
Visit this group at https://groups.google.com/group/object-composition.
For more options, visit https://groups.google.com/d/optout.
Matthew Browne
...
(Just noticed a small typo in my previous post—it's unimportant but bugs me enough to correct it ;) ..."some of its parts" should be "sum of its parts".)