## Use case
**Who is the customer and what insights do we have about them?**

**What is the prevailing customer problem/opportunity? what data informed this?**

**What is the solution? why is it the right solution to address the customer need versus other alternatives?**

**How would we describe the end-to-end customer experience (business flows)? what is the most important customer benefit?**
* Describe business flows using [domain storytelling](https://domainstorytelling.org/quick-start-guide), [story maps](https://www.mountaingoatsoftware.com/blog/user-story-mapping-how-to-create-story-maps), or [event storming](https://en.wikipedia.org/wiki/Event_storming). Use the Diagram and Business flows sections below. 
* Identify [bounded contexts](https://martinfowler.com/bliki/BoundedContext.html) and external dependencies. 
* Document business requirements using [EARS](https://alistairmavin.com/ears/) patterns: "while [optional pre-condition], when [optional trigger], the [system name] shall [system response]" (e.g., "while the user is signed-in, when the user asks to change the password, the application shall re-authenticate the user").

**How will we define and measure success?**

Consider writing [press release/frequently asked questions (PR/FAQ)](https://www.aboutamazon.com/news/workplace/an-insider-look-at-amazons-culture-and-processes) narrative ([example](https://www.allthingsdistributed.com/2024/11/aws-lambda-turns-10-a-rare-look-at-the-doc-that-started-it.html)) or [pitch](https://basecamp.com/shapeup/1.5-chapter-06) to further clarify the problem.

### Diagram
The diagram shall include all business flows to align requirements. Use a different color for each flow to differentiate between them.

### Business flows

#### [Title]
**Assumptions**

**Steps**

**Requirements**

## Architecture
Define architecture
* Define technical flows (e.g., load balancer → API → database; not ELB → AWS Lambda + Python → Amazon RDS) based on business flows. Use the Diagram and Technical flows sections below.
* Consider the following integration dimensions: 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. Use “fracture planes” 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. 
* Review decisions based on the following pillars: 1/ operational excellence 2/ security 3/ reliability 4/ performance efficiency 5/ cost optimization. 
* Document decisions using [architectural decision records (ADRs)](https://docs.aws.amazon.com/prescriptive-guidance/latest/architectural-decision-records/appendix.html).
* Document technical requirements using [EARS](https://alistairmavin.com/ears/) patterns: "while [optional pre-condition], when [optional trigger], the [system name] shall [system response]" (e.g., "while the deployment pipeline is running, when there is a change to the pipeline structure, the pipeline shall stop and restart with the new structure").

Choose technologies
* Consider building proof of concept (POC) for new technologies to validate feasibility.
* Review decisions based on the following pillars: 1/ operational excellence 2/ security 3/ reliability 4/ performance efficiency 5/ cost optimization.
* Document decisions using [architectural decision records (ADRs)](https://docs.aws.amazon.com/prescriptive-guidance/latest/architectural-decision-records/appendix.html).


### Diagram
The diagram shall include all technical flows to align requirements. Use a different color for each flow to differentiate between them.

### Technical flows

#### [Title]
**Assumptions**

**Steps**

**Requirements**

### Architectural decision records (ADRs)

#### Application boundaries
**Context**

**Options**

**Decision**

**Consequences**

#### Application X components
**Context**

**Options**

**Decision**

**Consequences**

#### [Title]
**Context**

**Options**

**Decision**

**Consequences**

## Code

### Git repositories
Application X: `application-x`

### Project structure
**Application X**