Application Design Framework (ADF)

Purpose

Reduce lead time by bridging product-to-engineering gaps.

Application boundary ^[1]:

Architecture ^[2][3]:

An architecture describes how components work together. How components communicate and interact is often the focus of architecture diagrams.

Component ^[4]:

Software components are things that are independently replaceable and upgradeable.

Application is an ownership boundary.

Application boundary should evolve with organizational and software changes.

Describe use case (Sales, Marketing, Product) to clarify problem and solution.

Describe business flow using domain storytelling and/or event storming.
Consider writing press release/frequently asked questions (PR/FAQ) narrative (example) or pitch.
Identify features, bounded contexts and external dependencies.
Describe business requirements.

Define architecture (Product, Engineering) to address business requirements.

Define technical flow (e.g., load balancer → API → database) based on business flow.
Use “fracture planes” ^[5] to help decide on application boundaries: 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.
Consider the following integration dimensions ^[6]: 1/ service discovery (e.g., IP addresses, DNS) 2/ data format (e.g., binary, XML, JSON, protobuf, Avro) 3/ interaction type (e.g., sync, async) 4/ interaction style (e.g., messaging, RPC, query, GraphQL).
Identify application boundaries and components.
Define technical requirements.

Choose technologies (Engineering) to address technical requirements.

Consider building proof of concept (POC) for new technologies to validate feasibility.
Review decisions based on the following pillars ^[7]: 1/ operational excellence 2/ security 3/ reliability 4/ performance efficiency 5/ cost optimization.
Document decisions using architectural decision records (ADRs).

Write stories (Product, Engineering) to scope implementation.

Use the following story types:
- User Story – “As a [type of user] I [want this thing] so that [I can accomplish this goal]”. Example: “As a site visitor, I want to see new content when I come to the site, so I come back more often”.
- Job Story – “When [situation], I want to [motivation], so I can [expected outcome]”. Example: “When it’s dinner time tonight, I want to have pizza so I can easily feed my friends”.
- Feature-Driven Development (FDD) – “[action] the [result] [by/for/of/to] a(n) [object]”. Example: “Generate a unique identifier for a transaction”.
Map stories to features.

Create one or more repositories and a single pipeline per application (Engineering) to reduce blast radius and increase delivery performance.

Organize resources configuration and business logic code by application components (Engineering) to align architecture with code.

AWS Well-Architected Framework - apply architectural best practices for designing and operating reliable, secure, efficient, cost-effective, and sustainable systems.
Operational Readiness Review - ensure a consistent review of operational readiness, with a specific focus on eliminating known, common causes of impact

Awesome Architecture - concepts and foundations, followed by jobs-to-be-done
AWS Decision Guides - choose the AWS services that might be right for you and your use cases

A mechanism for introducing ADF into organization (inputs, tools, adoption, inspection, iteration, outputs).
Organizing ADF information for multiple use cases and applications.
Using conditions of satisfaction (acceptance criteria) together with or instead of the requirements section.
Linking architecrual decision records (ADRs) to requirements and stories (e.g., referencing the related requirement(s) and story(ies) in ADR context) to check impact of an architectural change during design phase.

This site is open source. Improve this page.