Architectural subsystem

As explained in Architecture Modernization: Socio-technical alignment of software, strategy, and structure

A subsystem is a distinct part of a larger system that performs a related group of functions and interacts through defined boundaries.

An architectural subsystem is a part of a software system with a defined purpose and responsibilities. It might be a microservice, a module in a monolith, or another architectural unit. Its boundary matters more than its deployment form: when responsibilities align with a business subdomain and dependencies stay manageable, teams can change their parts of the system with fewer cross-team interruptions. section 12.0 section 12.3.1

A target architecture can align subsystems with subdomains, but legacy boundaries may not. Treat the boundary as a design hypothesis: examine how business scenarios cross it, then revise it when those scenarios expose awkward dependencies. Feedback from software design can also prompt changes to domain boundaries and team structure. section 12.0 section 12.2.3

When fewer boundaries work better

In an accounting-system redesign, a group initially drew four fine-grained boundaries. Testing them against real use cases led to two: fixed asset responsibilities, including sales, and computing tasks, including revaluation and depreciation. The larger, more cohesive subsystems reduced the complexity created by interactions between boundaries. Smaller was not automatically simpler. section 12.2.3

To review a proposed subsystem before committing to it:

• Test several real scenarios to see how subsystems communicate and where dependencies arise. section 12.2.3 section 12.3
• Consolidate what the scenarios reveal into one view of the subsystem; use a bounded context canvas to discuss its name, purpose, and strategic role. A precise name helps reveal misplaced responsibilities. section 12.3 section 12.3.1
• If the boundary remains uncertain, explore more detail through a code proof of concept or software design EventStorming. section 12.3

Figure 12.16 The bounded context canvas

The bounded context canvas offers a shared visual check of an individual subsystem’s design, including whether its responsibilities fit its business purpose. section 12.3.1

Once a boundary is credible, decide how much of that subsystem to modernize. A complete rewrite is only one option; weigh its potential return against its cost and the delay it could introduce. Plan the move from current to target state rather than treating the target design as the finished work. section 12.4

How Architecture Modernization: Socio-technical alignment of software, strategy, and structure covers it

How deep it goes

Defines the unit and develops boundary-review and modernization considerations, while leaving higher-level strategy and roadmaps for later.

Examples

Uses accounting-system boundary iterations and a discounts-subsystem canvas to make design choices concrete.

What it assumes

Assumes working familiarity with subdomains and business strategy classifications, while defining subsystem without requiring a particular deployment form.

What you can do after

Evaluate/understand subsystem boundaries through real use cases and a bounded context canvas before choosing a modernization investment.

How it connects

Connects subsystems to loose coupling, subdomains, bounded contexts, team structure, and modernization strategy.

liveBookmanning.com

Read Architecture Modernization: Socio-technical alignment of software, strategy, and structure on liveBook Get the book at manning.com

Related concepts

• facade patternused by · The facade pattern is a structural design pattern that provides a simplified interface to a complex subsystem or set of underlying components.
• model architecturepart of · The structural organization of a computational system’s components, relationships, and operations that determines how it processes information or behaves.
• componentequivalent to · A software component is a modular part of a larger system that provides related functionality and interacts with other parts through defined boundaries or interfaces.
• serviceaddressed by · A service is a software or computing capability that provides defined functionality to users or other components through an interaction boundary.
• architecture diagrampart of · An architecture diagram is a visual representation of a system’s major components and their structural relationships or interactions.

This explainer was generated by Manning's knowledge graph from the text of Architecture Modernization: Socio-technical alignment of software, strategy, and structure. The section links point to the parts of the book it draws on.