Beside the great points Kevin (@kmruiz
) already mentioned, I would like to add couple of points:
If the services are "chatty" when they talk to each others (via HTTP or whatsoever), you might wanna combine them into one service.
It's better to start by writing all the business capabilities (aka features) that a service should handle, and that's ideally before writing any line of code so that you could set the boundaries clearly.
Sometimes, it's very very OK to put everything into one service, and separate them later when the boundaries are clearer.
You won't get this right from the first iteration, DDD is like a programming-style that goes beyond the initial design, but also during the whole development.
Beside the great points Kevin (@kmruiz ) already mentioned, I would like to add couple of points:
If the services are "chatty" when they talk to each others (via HTTP or whatsoever), you might wanna combine them into one service.
It's better to start by writing all the business capabilities (aka features) that a service should handle, and that's ideally before writing any line of code so that you could set the boundaries clearly.
Sometimes, it's very very OK to put everything into one service, and separate them later when the boundaries are clearer.
You won't get this right from the first iteration, DDD is like a programming-style that goes beyond the initial design, but also during the whole development.
Thank you a lot for your great advices @kmruiz and @yaser they are inspiring !