Application Design Framework (ADF)

Align business with technology, minimize rework, ease evolution.


Building products and services requires companies to be responsive to market signals and demand. Some companies struggle with business agility due to misalignment between business and technology. This misalignment results in significant rework and a difficult to evolve architecture.

Application Design Framework (ADF) aims to help address these challenges by introducing a set of recommendations and a document template. ADF document integrates decisions across product engineering steps in a single place to maintain alignment.


Application boundary [1]:

Architecture [2][3]:

Component [4]:


Application is an ownership boundary.

Application boundary should evolve with organizational and software changes.


ADF introduces the following recommendations along with related personas:

  1. Capture use cases [Sales, Marketing, Product] to clarify problem and solution. Consider writing press release/frequently asked questions (PR/FAQ) or pitch.
  2. Write stories and flows [Product, Engineering] to start conversation about requirements. Consider using event storming.
  3. Define requirements [Product, Engineering] to guide architectural decisions. Consider functional and non-functional requirements.
  4. Define architecture [Product, Engineering] to address requirements. Describe stories and flows on architecture level. Identify applications. Validate application boundaries using the following “fracture planes” [5]: 1/ Profit and Loss Group 2/ Business Domain Bounded Context 3/ Regulatory Compliance 4/ Change Cadence 5/ Team Location 6/ Risk 7/ Performance Isolation 8/ Technology 9/ User Personas. Capture Architectural Decision Records (ADRs) including “why” behind decisions, options considered, trade-offs, and consequences. ADRs allow to evolve the architecture starting from known design considerations. Consider building proof of concept (POC) to validate the decisions.
  5. Create one or more repositories and a single pipeline per application [Engineering] to reduce blast radius and increase delivery performance.
  6. Organize resources configuration and business logic per application component [Engineering] to align architecture and implementation. It should ease evolution and maintenance.




  1. Martin Fowler - ApplicationBoundary
  2. AWS Well-Architected Framework - Definitions
  3. Neal Ford and Mark Richards - Software Architecture: the Hard Parts
  4. Martin Fowler - SoftwareComponent
  5. Matthew Skelton - Designing organizations for responsiveness