Application Design - Detailed Steps
Architecture design rules
Application Design - Detailed Steps
Purpose
High-level component identification and service layer design
Application Design focuses on:
- Identifying main functional components and their responsibilities
- Defining component interfaces (not detailed business logic)
- Designing service layer for orchestration
- Establishing component dependencies and communication patterns
Note: Detailed business logic design happens later in Functional Design (per-unit, CONSTRUCTION phase)
Prerequisites
- Context Assessment must be complete
- Requirements Assessment recommended (provides functional context)
- Story Development recommended (user stories guide design decisions)
- Execution plan must indicate Application Design stage should execute
Step-by-Step Execution
1. Analyze Context
- Read
aidlc-docs/inception/requirements/requirements.mdandaidlc-docs/inception/user-stories/stories.md - Identify key business capabilities and functional areas
- Determine design scope and complexity
2. Create Application Design Plan
- Generate plan with checkboxes [] for application design
- Focus on components, responsibilities, methods, business rules, and services
- Each step and sub-step should have a checkbox []
3. Include Mandatory Design Artifacts in Plan
- ALWAYS include these mandatory artifacts in the design plan:
- Generate components.md with component definitions and high-level responsibilities
- Generate component-methods.md with method signatures (business rules detailed later in Functional Design)
- Generate services.md with service definitions and orchestration patterns
- Generate component-dependency.md with dependency relationships and communication patterns
- Validate design completeness and consistency
4. Generate Context-Appropriate Questions
DIRECTIVE: Analyze the requirements and stories to generate ONLY questions relevant to THIS specific application design. Use the categories below as inspiration, NOT as a mandatory checklist. Skip entire categories if not applicable.
- EMBED questions using [Answer]: tag format
- Focus on ambiguities and missing information specific to this context
- Generate questions only where user input is needed for design decisions
Example question categories (adapt as needed):
- Component Identification - Only if component boundaries or organization is unclear
- Component Methods - Only if method signatures need clarification (detailed business rules come later)
- Service Layer Design - Only if service orchestration or boundaries are ambiguous
- Component Dependencies - Only if communication patterns or dependency management is unclear
- Design Patterns - Only if architectural style or pattern choice needs user input
5. Store Application Design Plan
- Save as
aidlc-docs/inception/plans/application-design-plan.md - Include all [Answer]: tags for user input
- Ensure plan covers all design aspects
6. Request User Input
- Ask user to fill [Answer]: tags directly in the plan document
- Emphasize importance of design decisions
- Provide clear instructions on completing the [Answer]: tags
7. Collect Answers
- Wait for user to provide answers to all questions using [Answer]: tags in the document
- Do not proceed until ALL [Answer]: tags are completed
- Review the document to ensure no [Answer]: tags are left blank
8. ANALYZE ANSWERS (MANDATORY)
Before proceeding, you MUST carefully review all user answers for:
- Vague or ambiguous responses: "mix of", "somewhere between", "not sure", "depends"
- Undefined criteria or terms: References to concepts without clear definitions
- Contradictory answers: Responses that conflict with each other
- Missing design details: Answers that lack specific guidance
- Answers that combine options: Responses that merge different approaches without clear decision rules
9. MANDATORY Follow-up Questions
If the analysis in step 8 reveals ANY ambiguous answers, you MUST:
- Add specific follow-up questions to the plan document using [Answer]: tags
- DO NOT proceed to approval until all ambiguities are resolved
- Examples of required follow-ups:
- "You mentioned 'mix of A and B' - what specific criteria should determine when to use A vs B?"
- "You said 'somewhere between A and B' - can you define the exact middle ground approach?"
- "You indicated 'not sure' - what additional information would help you decide?"
- "You mentioned 'depends on complexity' - how do you define complexity levels?"
10. Generate Application Design Artifacts
- Execute the approved plan to generate design artifacts
- Create
aidlc-docs/inception/application-design/components.mdwith:- Component name and purpose
- Component responsibilities
- Component interfaces
- Create
aidlc-docs/inception/application-design/component-methods.mdwith:- Method signatures for each component
- High-level purpose of each method
- Input/output types
- Note: Detailed business rules will be defined in Functional Design (per-unit, CONSTRUCTION phase)
- Create
aidlc-docs/inception/application-design/services.mdwith:- Service definitions
- Service responsibilities
- Service interactions and orchestration
- Create
aidlc-docs/inception/application-design/component-dependency.mdwith:- Dependency matrix showing relationships
- Communication patterns between components
- Data flow diagrams
- Create
aidlc-docs/inception/application-design/application-design.mdthat consolidates the multiple design docs created above in a single doc.
11. Log Approval
- Log approval prompt with timestamp in
aidlc-docs/audit.md - Include complete approval prompt text
- Use ISO 8601 timestamp format
12. Present Completion Message
# 🏗️ Application Design Complete
[AI-generated summary of application design artifacts created in bullet points]
> **📋 <u>**REVIEW REQUIRED:**</u>**
> Please examine the application design artifacts at: `aidlc-docs/inception/application-design/`
> **🚀 <u>**WHAT'S NEXT?**</u>**
>
> **You may:**
>
> 🔧 **Request Changes** - Ask for modifications to the application design if required
> [IF Units Generation is skipped:]
> 📝 **Add Units Generation** - Choose to include **Units Generation** stage (currently skipped)
> ✅ **Approve & Continue** - Approve design and proceed to **[Units Generation/CONSTRUCTION PHASE]**
13. Wait for Explicit Approval
- Do not proceed until the user explicitly approves the application design
- Approval must be clear and unambiguous
- If user requests changes, update the design and repeat the approval process
14. Record Approval Response
- Log the user's approval response with timestamp in
aidlc-docs/audit.md - Include the exact user response text
- Mark the approval status clearly
15. Update Progress
- Mark Application Design stage complete in
aidlc-docs/aidlc-state.md - Update the "Current Status" section
- Prepare for transition to next stage