Thread by @jamesmh_dev

Microservices != Bounded contexts.

Ex. We might have BCs payments, shipping, warehouse, search, etc.

Payments + shipping *could* be part of a well organized monolith.

Warehouse and search could be independently deployed processes/services (thread)

#dddesign

BCs are about conceptual boundaries that keep contextual language consistent inside it's own bubble, makes a specific problem+solution focused and easier to manage.

MSs are usually "discovered" or mapped well from BCs - but a BC doesn't have to be a MS.

MSs are about keeping the boundaries clear but also about making the "bubble" independently deployable.

This is why I think the discussions and fascination with microservices is usually premature. First, you should generally understand what your context boundaries are. Then, it might make sense to "promote" some BCs as microservices 🤔

But, it might not... If you are a small dev team then the overhead of MSs may not be worth it. But still having well defined boundaries is essential.

Got lots of teams? Then MSs are a good way to let each team flourish efficiently.

But, a small dev team may want to promote a BC to a MS due to business needs like:

- Availability
- High throughput/high traffic
- Critical piece may need faster build and test times
- Known to be a piece that will evolve alot so independent deploys are more efficient

- Codebase is highly classified and requires more strict access than other codebase(s)
- Non-functional requirement that is best met by certain infrastructure (serverless, cloud-whatever, etc)
- Specific problem solved best using a totally different tech stack altogether

At the end of the day, don't assume microservice are "best". Systems are dynamic and factors like team size, team experience/skill, company size, problem domain size, business requirements, current tech, etc all affect things!