Very nice and useful presentation. The case where we have a distinct team per module is a very particular case. The division of domains is very different by domain and by type of customer in that domain. So you can have several good variations of how teams are associated with modules, and we can't use the team argument to decide the design of our modules in one way. An example of domain segmentation: 4 main domain areas, a domain area has 10-15 subdomains and a subdomain could have between 5 and 40 modules, where we can also have sub-subdomains. The domain segmentation comes rather from the business side and we need to reflect that in our design. Domains are very different and we cannot take the examples for implementing one domain to implement another. The factors influencing the decision could be more like this: business-> design -> teams, while we can adjust the design elements vs the politics of the teams (also to avoid paying the high price for Conway's Law effects.) Microservices themselves cannot be a deciding factor ~ we split the domain to fit microservices. That is, the default design dictates the segmentation of the domain. Rather, we segment the business according to the business rules and then see at what level microservices can be applied. Segmentation doesn't start and end with microservices.
Hi Victor, after watching your videos, I find some over-engineering in my code everytime :+1: Thanks for your input, opinions and impulses for self-reflection!
We have used also another way of avoiding circular dependencies for the cases when module A wants something from module B. The initial variant was based on command + event, but the event was too expensive, so we replace the event with an observer-like interface.
Hi Victor Great talk. Can you maybe also show an example of a modularized monolithic spring boot application? I guess using packages for modules does not provider enough restriction and is more difficult to tear out into a microservice when the need arises. Thank you! Will join the community.
Great presentation!
I received confirmation of many of my thoughts and my experience.
Thank you so much! 👍
Victor, this was an awesome presentation! Thank you for sharing so much knowledge with the community :)
Great talk, are there any strong examples of this online in a git repo that you can share ?
I'm also interested in that, have you find any good examples?
Very nice and useful presentation.
The case where we have a distinct team per module is a very particular case. The division of domains is very different by domain and by type of customer in that domain. So you can have several good variations of how teams are associated with modules, and we can't use the team argument to decide the design of our modules in one way.
An example of domain segmentation: 4 main domain areas, a domain area has 10-15 subdomains and a subdomain could have between 5 and 40 modules, where we can also have sub-subdomains. The domain segmentation comes rather from the business side and we need to reflect that in our design.
Domains are very different and we cannot take the examples for implementing one domain to implement another.
The factors influencing the decision could be more like this: business-> design -> teams, while we can adjust the design elements vs the politics of the teams (also to avoid paying the high price for Conway's Law effects.)
Microservices themselves cannot be a deciding factor ~ we split the domain to fit microservices. That is, the default design dictates the segmentation of the domain.
Rather, we segment the business according to the business rules and then see at what level microservices can be applied. Segmentation doesn't start and end with microservices.
Hi Victor, after watching your videos, I find some over-engineering in my code everytime :+1: Thanks for your input, opinions and impulses for self-reflection!
We have used also another way of avoiding circular dependencies for the cases when module A wants something from module B. The initial variant was based on command + event, but the event was too expensive, so we replace the event with an observer-like interface.
Hi Victor
Great talk. Can you maybe also show an example of a modularized monolithic spring boot application? I guess using packages for modules does not provider enough restriction and is more difficult to tear out into a microservice when the need arises. Thank you! Will join the community.