Monolith first or Microservices first!
You are good to write #microservices if you can write good monoliths!
If you are starting on green field (new domain/ rewriting existing domain) project, it is better to start with monolith. Following are things which will be helpful for development team to keep in mind.
- Understand THE Domain. Talk in terms of Domain experts language (and not tables and columns). As you learn more about Domain, enhance code to reflect it. This is iterative process. Keep refactoring code as you learn more about domain!
- High cohesion and loose coupling. (This applies no matter you are building small, medium or large systems).
- Use Bounded Context — Write Monoliths, but keeping in mind bounded contexts. E.g instead of using Canonical models, find out bounded contexts. E.g in online retail domain, Order, Catalog, Payment can be different bounded contexts. Also Item in Order is going to be different than Item in Catalog. So instead of building canonical model with just One Item class, use Different Item class in Order bounded context and different Item class in Catalog bounded context. With monolith you can use modules to keep these domain classes of different bounded contexts seperate.
- Keep watch on transaction boundaries (ACID). Avoid doing transactions across Aggregates(object) of bounded contexts. This is important when you will later need to split monolith into different microservices. As each microservice will have its own database, having transactions across bounded context will mean that you will need distributed transactions (which are hard). So Keep in mind that ACID transaction should not span across bounded contexts.
- Use Aggregates, Entities, Value Objects, Domain Services, and Domain Events to build monoliths if possible.
- Deploy your Monolith.
- Did your Monolith bring you lot of business, go on and split monolith to microservices.
- Each microservice should have its own database.
- Microservices should talk to each other using Events. Http calls between microservices will become trouble sooner or later.
- Use event sourcing and CQRS if your product becomes tremendously successful.
Code — Work in progress on my github repo (all repos starting with eshop)
This code uses cut-down version of online shop and is implementing it using DDD, Event Sourcing and CQRS