I got a notification email from Medium.com saying that one of my comments on Microservices related article was attracting attention. It’s been a while since I’ve made that comment, so I’ve reviewed it and figured it makes sense to copy it to my personal page for reference sake.
With that comment I wanted to remind about the importance of SOA and indicate that various implementation patterns should be thought out, not simply adopted and followed just because someone else did it this way.
Here is the article and here is the link to my comment there. Below is the comment itself.
Microservices is simply an implementation technique. Unfortunately there is too much hype around this buzz word and too few make connection to the underlying architecture that is important here — SOA. Without proper understanding and application of SOA, EDA and DDD you will struggle and, most likely, fail. Well, you’ll struggle regardless, but failing becomes optional.
What’s important with any large problem domain is to:
- Understand if distributed architecture is what you *really* need. It’s not a walk in a park.
- Analyze your problem domain, identify your solution domains and bounded contexts.
- If you see a need to apply different non-functional aspects to your bounded contexts (actually, aggregates within those) — think about splitting those into separate deployment modules (services, executables, whatever you want). You may decide against it. Nothing wrong with that. If you decide to go for it — at this point you should really consider EDA.
- With EDA come eventual consistency. Not for your aggregates (see DDD Aggregates) but between aggregates / bounded contexts.
- User initiated processes / requests should be modeled with aggregates and provide a synchronous, encapsulated implementation. There should be NO distributed transactions — you will never conquer those.
- Think whether keeping a local (for a given bounded context or subdomain) cache of critical data from other aggregates / bounded contexts / subdomains makes sense (very often it does).
- Definitely think about composite UI.
- Don’t forget that reporting / BI use cases can build their own view of the system world.
- etc, etc, etc
As for data storage. Be pragmatic (as with anything). If one DB works for all services — why not partition it with schemas? Just make sure not to share the schemas and keep them private for each SOA Service (not microservice — microservice is just a deployment artifact). If polyglot persistence is what makes sense — go for it.