Decomposition Patterns - Part One

Topic: Software Design                                                                                  Level: Intermediate

Decomposition Patterns - What?

Breaking down the architectural design with respect to a defined context

1. Decompose By Business Capability

Decomposing the service architecture based on an organization's business functional units that are delivering around the business values.

Understanding the areas of business models, operations, structure, processes, and each unit's isolation boundary aids in designing services that correspond to a particular functional business capability.

For instance, a business that provides a cab/ride service has the following functional capabilities like 

• FeeEstimateCalculatorManagement
• RideAvailabilityManagement
• RideCatalogManagement
• PaymentModeManagement
• RideReportAnalyticsManagement
• LogisticsManagment
• ProfilesManagement 

Each of the capabilities is decoupled from each other with different business operational boundaries making them the ideal candidates for decomposing the business into a microservice architecture.

The resultant design is cohesive and loosely coupled providing the ability to scale (RideAvailabilityService, FeeEstimateCalculatorService) on demand, isolated change management (RideCatalogService, PaymentService), batch reporting (ReportAnalyticsService, ProfilesService), and health monitoring availability checks on individual services.

The organization orchestrates multiple lines of business for its operations, and the architectural pattern orchestrates multiple microservices for its seamless service delivery.

2. Decompose By Subdomain

The Domain Driven Design(DDD) approach in identifying the subdomains, which is granular in model categorizations within the encapsulating domain of business capabilities. Otherwise, the subdomains are defined by recursively refining the domain to its lowest functional levels based on its respective business capabilities.

The subdomains in turn can be classified based on the business functionality that it is responsible for, usually labelled as 

• CORE (key enabler for the business) 
• SUPPORT (endorser for the business) 
• GENERIC (non-business specifics)

The subdomain extends up to a defined scope of bounded context and service is developed around this context of the subdomain. Loosely coupled architecture provides scalability, resilience, maintainability, extensibility, location transparency, protocol independence, and time independence.

For instance, the ProfileManagement domain has subdomain models for User, Driver, and Business contexts shown below. 

The downside to such a fine-grained definition is the number of microservices required for each domain model increases making it difficult to manage & orchestrate.

3. Decompose By Transaction

The pattern of identifying and establishing the business boundaries corresponding to the  transaction contexts. Services defined with such a pattern handle the transaction holistically, right from the request initiation to the culminating response. 

The entire transaction lifecycle resides within the service as the pattern eliminates the need for the transaction to coordinate/call back multiple services to complete a given business request. (the request never exits the service and gets handled within)

As the transaction boundaries reside within the same service the response times of such a design are faster, ensuring data consistency and availability. 

For instance, multiple modules have to be collectively combined as a simple ride booking transaction traverses through each service level, say from Catalog, Availability, FeeEstimate, PaymentMode, etc.,

However, designing based on transaction boundaries might require multiple modules to be coupled together leading to a monolithic system design, that encircles the transaction lifecycle.

More to lance on the decomposition patterns, check back soon on Part Two.

---

Disclaimer: 

This is a personal blog. Any views or opinions represented in this blog are personal and belong solely to the blog owner and do not represent those of people, institutions or organizations that the owner may or may not be associated with in professional or personal capacity, unless explicitly stated. Any views or opinions are not intended to malign any religion, ethnic group, club, organization, company, or individual. All content provided on this blog is for informational purposes only. The owner of this blog makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site. The owner will not be liable for any errors or omissions in this information nor for the availability of this information. The owner will not be liable for any losses, injuries, or damages from the display or use of this information.

Downloadable Files and Images

Any downloadable file, including but not limited to pdfs, docs, jpegs, pngs, is provided at the user’s own risk. The owner will not be liable for any losses, injuries, or damages resulting from a corrupted or damaged file.

• Comments are welcome. However, the blog owner reserves the right to edit or delete any comments submitted to this blog without notice due to :
• Comments deemed to be spam or questionable spam.
• Comments including profanity.
• Comments containing language or concepts that could be deemed offensive.
• Comments containing hate speech, credible threats, or direct attacks on an individual or group.

The blog owner is not responsible for the content in the comments.

This blog disclaimer is subject to change at any time.