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:
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.
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.
Let's take an e-commerce as a popular sample. It's business capabilities are:
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.
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.
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.
These are my courses you should definitely check out on Pluralsight: