I’m finally seeing the “microservice” trend starting to fade a bit. An excellent article came through my Twitter feed the other day, Sean Kelly’s “Microservices, please don’t.” His stuff is remarkable for how he draws the connection between coding practices in a monolith and their equivalent in a microservices architecture. It seems obvious but I haven’t seen too many people pay attention to it.
A solid SOA approach begins in the code itself and moves out into the physical topology of the stack as time moves on.
One of the issues that should be addressed in SOA is how to avoid shackling services together. A simple change in one of them shouldn’t create a cascading set of changes across multiple services. Likewise code in a monolith should be architected to isolate change and prevent cascading updates across classes or packages.
Domain-Driven Design addresses this issue for the single application and some of its rules apply equally well. For example, don’t pass the same object around inside the application that you pass across externally. There’s always a layer in true DDD applications that takes any DTO from an external source (like a web service or database) and keeps it external to the application by translating it to another object in the language of the domain inside the application. There’s a huge temptation to skip this step but every time I’ve seen it done it creates huge problems at some point.
Likewise in a microservices world, the requests and responses chattering between the services should never be a reverse dependency that force all of the services to change whenever they do, whether the specific service cares about the change or not. There should be a good fencing strategy going on that allows them to change with a minimum of pain. And that’s really no different than all of the classic object-oriented design advice. Keep in mind that Uncle Bob’s definition of “single responsibility” is “one reason to change”–not some of the other common misunderstandings passed around.
Anyway, the bottom line point in this is what software luminaries have always known and said: there’s no architecture, no ceremony or formula that you can follow which will not crumble when divorced from the context of good underlying engineering principles .