Software architecture shapes how a system can change. A tightly coupled legacy system can make releases risky and slow; a carefully designed architecture can help teams deliver value sooner. The choice is not just technical: domain boundaries, team ownership, and business outcomes all affect whether change can flow independently. section 1.0 section 1.5
An independent value stream brings these concerns together: it pursues a business outcome, belongs to an autonomous team, and has decoupled software aligned to a loosely coupled business subdomain. If software and team boundaries disagree, people may have to share codebases and coordinate changes that should be independent. section 6.1.1 section 11.1.6
Finding boundaries at an airline
An airline’s monolith was risky to change, required whole-system deployments, and remained unreliable at peak traffic. Stakeholders used EventStorming to explore the current system and identify domains and subdomains. They grouped related work where concepts crossed boundaries, while identifying subdomains that teams could largely own independently. The proposed structure reflected business language rather than an arbitrary split of the code. section 9.3.4
To examine an architecture, work progressively rather than assuming the first map is final:
- Name the business outcomes the current system obstructs. section 9.3.4
- Map domains and subdomains with stakeholders, checking where changes are coupled. section 9.3.4
- Compare those boundaries with team ownership and communication patterns. section 11.1.6
- Revisit decisions as the business and system change; modernization is an evolutionary journey, not a fixed target design. section 1.5
Use the four characteristics of an independent value stream to check whether business purpose, subdomain, team ownership, and software boundaries reinforce one another. section 6.1.1












