Decomposition Techniques in Software Architecture
Decomposition is an important part of software architecture process. Especially if your system is relatively large, however this is not a limitation. Decomposition is a process of splitting your system in smaller chunks, because as people we work better by working on smaller separate tasks, rather than a large system which is hard to grasp. It's an essential an simple idea, utilised everywhere in software. Once the system is decomposed, you can think what to do further, for instance:
- work on each chunk in different times
- give each chunk to a separate person/team so the work can be done in parallel
- make every chunk platform and language agnostic - that's like an edge case but sometimes it's practical - you can let's say write one part of code in C# and another one in Java.
Does it remind you anything? ... it sounds lie microservices and you're right, however microservices only borrowed this idea but not invented one. The practice exists for years, it's just with microservices you've got it on a new level, not always the better one.
Decompose by Business Capability
This technique is about splitting the system in components corresponding to business capabilities. Business capability is something that 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
Let's take an e-commerce as a popular sample. It's business capabilities are:
- Product catalog management
- Inventory management
- Order management
- Delivery management
The correspondng architecture will consists of 4 of those components.
This is the most common approach, especially in modern trend of migrating applications from monolith to microservices.
At the end, this approach is guiding the system design to to the way the business is structured which reminds us about 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. Apparently, the pro of this approach is to ensure alignment between development teams and business structural units. And the con is that businesses are not always functioning efficiently, therefore your design might actually reflect these inefficiencies in the physical system. If that's the case, you might want to consider the next approach.
Decompose by Subdomain
It's an almost idential approach to the previous one, however it involves understanding the business domian and applying Domain Driven Design to your application architecture. Essentially, the more you work on a particular domain, the more you start understanding the business. Once you domain model grows, you will start creating subdomains or bounded contexts therefore decomposing is easy - you essentially map a bounded context to a component.
The pro of this approach is that it can lead the system design to what closely resembles the reality of what is happening or what needs to happen, however current business structure may not always align with that.
Reasoning
Essentially, I coundn't find more approaches that these two, at least on high level. You can mix both, nest one within another i.e. decompose application by business capability, and within that component decompose by subdomain etc.
Neither approach is mutually exclusive, and you will probably end up with a compromise attempt to balance domain design with business capabilities.
Thanks for reading. If you would like to follow up with future posts please subscribe to my rss feed and/or follow me on twitter.