Hello Kevin, thanks a lot this article is really great ! Keep the good work :)
I have 2 questions for you:
1) When you write "It might look like a microservices architecture, but it's not, because services are highly coupled between them so neither services nor teams are autonomous."
I understand the collision here and the difficulties of teams working on the same codebase, but I feel that if even if we split it in 2 microservices, the dependency will remain, as the checkout team needs info from stock to complete a checkout.
Hence, the checkout team will ask for more feature to checkout team, and the slowness and coupling will remain
I don't see how to decouple things here, maybe I failed to understand your solution ?
2) When you talk about the term "Products", If I understand well it designates:
Profile Sign up
1 click purchase
Bestseller page
Search by genre and author
...
It sounds a bit odd for me, because I naturally tend to think that the product is Shopping Plateform, and "1 click purchase" and so on are Features.
Hi Vivien, thanks for your feedback! Let me try to answer and clarify your questions :).
1) Systems need to interact with other systems to remain useful and when there is interaction, there is some coupling. You can earn some benefits, like availability and team performance, when this coupling is temporary.
For example, if you have a CheckoutService and every time you want to buy a book you need to query the StockService (through a HTTP endpoint or any other way) you have direct coupling every time you need the information.
If you invert the communication, and the StockService or any other peer offers you updates on the stock through a broadcast mechanism, you don't mind if the StockService is down or not, you only need the updates in a place where you can read it and doesn't depend on the availability of the service. You need someone to provide the information, but you only need to agree just on the format and the quantity of information you need.
With Apache Kafka, for example, if you configure your partitions in a specific way (partition key = domain id) and you implement a state-sourcing mechanism, you don't even need any service to replay states when you implement new functionality because you can replay the state by yourself.
2) There is a book named Lean Inception written by a Thoughtworks colleague (Paulo Caroli) that uses the name MVP for defining products that can be deliverable in a predictive way. Those MVPs are bound to a set of personas (you focus on solving the problems of a single type of user), a set of user journeys for that personas, and you define an autonomous way to measure the success of the MVP.
This mechanism (that's from my side, not part of the book) allows business to define a set of products that have a relationship between them and can be evolved independently of other products. You usually will build new products when you want to widen the impact of your platform or experiment on new business slices, and you will implement new features on a MVP when you want to optimize the revenue you have from an already known subset of personas.
Thinking in a business as a "platform" of products allows us to define boundaries that are relevant for the business, autonomous, and have impact on business metrics. It's just a way of defining boundaries that is a bit different, but it doesn't necessarily mean it's right :D. I've used it a couple of times in different teams and it worked quite well.
Please feel free to follow up here if the answers were not clear enough.
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.
Hello Kevin, thanks a lot this article is really great ! Keep the good work :)
I have 2 questions for you:
1) When you write "It might look like a microservices architecture, but it's not, because services are highly coupled between them so neither services nor teams are autonomous."
I understand the collision here and the difficulties of teams working on the same codebase, but I feel that if even if we split it in 2 microservices, the dependency will remain, as the checkout team needs info from stock to complete a checkout.
Hence, the checkout team will ask for more feature to checkout team, and the slowness and coupling will remain
I don't see how to decouple things here, maybe I failed to understand your solution ?
2) When you talk about the term "Products", If I understand well it designates:
It sounds a bit odd for me, because I naturally tend to think that the product is Shopping Plateform, and "1 click purchase" and so on are Features.
Is "Product" a term of DDD ?
Hi Vivien, thanks for your feedback! Let me try to answer and clarify your questions :).
1) Systems need to interact with other systems to remain useful and when there is interaction, there is some coupling. You can earn some benefits, like availability and team performance, when this coupling is temporary.
For example, if you have a CheckoutService and every time you want to buy a book you need to query the StockService (through a HTTP endpoint or any other way) you have direct coupling every time you need the information.
If you invert the communication, and the StockService or any other peer offers you updates on the stock through a broadcast mechanism, you don't mind if the StockService is down or not, you only need the updates in a place where you can read it and doesn't depend on the availability of the service. You need someone to provide the information, but you only need to agree just on the format and the quantity of information you need.
With Apache Kafka, for example, if you configure your partitions in a specific way (partition key = domain id) and you implement a state-sourcing mechanism, you don't even need any service to replay states when you implement new functionality because you can replay the state by yourself.
2) There is a book named Lean Inception written by a Thoughtworks colleague (Paulo Caroli) that uses the name MVP for defining products that can be deliverable in a predictive way. Those MVPs are bound to a set of personas (you focus on solving the problems of a single type of user), a set of user journeys for that personas, and you define an autonomous way to measure the success of the MVP.
This mechanism (that's from my side, not part of the book) allows business to define a set of products that have a relationship between them and can be evolved independently of other products. You usually will build new products when you want to widen the impact of your platform or experiment on new business slices, and you will implement new features on a MVP when you want to optimize the revenue you have from an already known subset of personas.
Thinking in a business as a "platform" of products allows us to define boundaries that are relevant for the business, autonomous, and have impact on business metrics. It's just a way of defining boundaries that is a bit different, but it doesn't necessarily mean it's right :D. I've used it a couple of times in different teams and it worked quite well.
Please feel free to follow up here if the answers were not clear enough.
Thanks!
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 !