Menu
As I read, there are two patterns to define one microservice, by business capability and by subdomain. But I still find it very ambiguous. I get confused how these two patterns differentiate from each other. Both of them revolve around activities involving an area of business logic. All of components in each service are small enough to get packaged with each other without affecting other services. Could anyone please give me a further explanation about these two?
536
A business capability is a concept from business architecture modeling. It is something that a business does in order to generate value. A business capability often corresponds to a business object, e.g. Order Management is responsible for orders. Customer Management is responsible for customers.
Microservices Decomposition Pattern — Decompose by SubdomainDDD refers to the application's problem space the business as the domain. A domain is consists of multiple subdomains. Each subdomain corresponds to a different part of the business.
One strategy for creating a microservice architecture is to decompose by business capability. A business capability is a concept from business architecture modeling. A business capability is something that a business does in order to generate value.
We can define a microservice corresponding to Domain-Driven Design(DDD) subdomains. DDD refers to business as a domain and a domain can have multiple subdomains. Now each subdomain refers to different areas. For Example − Order Management − Order Management subdomain refers to Orders.
The commenters are right - there are some subjective definitions at play here. But there are some principles and concepts that can help reason about the different approaches.
It's not strictly the original definition, but I think the distinction can be better understood with reference to Conway's Law:
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
Following from that thinking, the Inverse Conway Maneuver evolved:
The 'Inverse Conway Maneuver' recommends evolving your team and organizational structure to promote your desired architecture. Ideally your technology architecture will display isomorphism with your business architecture.
The Inverse Conway Maneuver is an attempt to structure your organisation to harness Conway's Law to achieve a better system design.
With an understanding of these concepts, we can consider decomposition by Business Capability to be guiding the system design according to the way the business is structured. This echos Conway's law.
The pro of this approach is it helps to ensure alignment between development teams and business structural units. The con is it may bake business inefficiencies that arose before an automated system was considered, into the design of your system.
Domain Driven Design (DDD) provides a suite of tools and methodologies to reason about the underlying domain at hand, to reflect the best available understanding of the domain in the software design and to evolve the software design as understanding of the domain grows and changes. DDD Strategic Patterns guide the creation of a Context Map which can form the foundation of your microservices decomposition.
From this, we can consider decomposition by Domain to be guiding the system design according to an analysis of the processes and information flows .
The pro of this approach is that it can lead to a system design that closely models the reality of what is happening (or needs to happen). Hopefully the business structure already aligns with this - but where it doesn't, it can reveal inefficiencies in the existing business organisational structure.
If you have influence over the organisational structure, this can be a foundation for utilising the Inverse Conway Maneuver and to allow you to evolve the software, the dev teams and the business units to achieve alignment.
If you don't, you may end up introducing friction points where the system design becomes misaligned with the business capabilities.
The reality is, neither approach is mutually exclusive - you will probably end up with a compromise that attempts to balance alignment with business capabilities as they are already understood and problem domains as they are revealed through a DDD process.
80
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
