As for a Mvp purposes, you do not actually need tons of micro-services, but that also does not mean you have to write a code which does not represent it`s business language and is also non-scalable, such as spoken from other StartUps founders which have succeeded about their Companies early stage.
Ex:
Consider a system having classes for Business operations by Entity "UserService; AddressService; TermsService". These leads to more code written, business rules redundancy, logic errors and imposes some barriers on understanding the business language and flows.
I should mention that this is a violation on some of DDD aspects such as Context and Aggregates Boundaries.
The focus should be on creating classes for Domain Operations by Business Contexts. Which means that there will be many contexts in a single monolithic service. But that should never be a problem for few users and a MVP.
Data redundancy is not a bad thing if you have the time and money to deal with the consistency it requires, so you should not worry about mixing your business contexts at some point. But! You should avoid it.
The reason to do so, is that for the MVP, you can write new features faster, scale faster and deliver better user experiences. So when its time to grow and create a microservice for your contexts, your system will have an easy decoupling of code when it is to grow for your context.
When decoupling your contexts into micro-services, is important to keep two factors in mind.
- You can keep some of pieces of the data between the contexts.
- These pieces of data can mutate while decoupling, in order to make it more independent. For Ex: Keeping the likes count on post Context, and the move the entities such as like and comments to "SocialInteractions Microservice", which was a context mixed with the posts context in a single micro-service.
Ex By Business Entities :
Ex By Context:
Both have quite the same amount of features and also The By context example have many less lines of code
Top comments (0)