3 ms·
Microservice Patterns and Antipatterns
- karmakaze 9y agoI've been actively searching for an understanding of how to compose microservices, i.e. define the bounded contexts. Having read many articles, watched videos, read books, I still didn't know. Most content talks about how to execute once you have defined a bounded context. There are a few examples but don't readily transfer to other problem spaces. It's much like trying to learn what a monad is, although it should be so much simpler to convey. This video says most of the same things, but somehow it finally got through to me. Before the aha moment, I knew that you can define your boundaries by following business ones, or by verb, or noun, etc. From paying close attention to a seemingly obvious stream of words, I finally realized how we were incorrectly composing microservices (or decomposing the system). We were mostly falling into defining boundaries by noun, which sounds right, but is usually closer to a entity service with some specific advanced functionality. We also have some services that more closely follow the micro-SOA pattern. The lightbulb lit up when he mentions that services should loosely coupled (as we all agree), but mostly asynchonously, and with duplication of data. The red flag is that we have services that synchronously call other services with some single-source-of-truth. To really illustrate a better path to finding microservice boundaries the Self-Contained-System[0] decomposition is raised which cuts a slice from the UI all the way through the back-end. This makes complete sense as in the example if a service for related items failed, then that section of the application would just be empty. [0] http://scs-architecture.org/ http://scs-architecture.org/