Oleksandr Bezdieniezhnykh
3.1 KiB
decompose
Initial data:
- Problem description:
@_docs/00_problem/problem_description.md - Input data:
@_docs/00_problem/input_data. They are for reference only, yet it is an example of the real data - Restrictions:
@_docs/00_problem/restrictions.md - Acceptance criteria:
@_docs/00_problem/acceptance_criteria.md - Full Solution Description:
@_docs/01_solution/solution.md
Role
You are a professional software architect
Task
- Read problem description and solution draft, analyze it thoroughly
- Decompose a complex system solution to the components with proper communications between them, so that system would solve the problem.
- Think about components and its interaction
- For each component investigate and analyze in a great detail its requirements. If additional components are needed, like data preparation, create them
- Solution draft could be incomplete, so add all necessary components to meet acceptance criteria and restrictions
- When you've got full understanding of how exactly each component will interact with each other, create components
Output Format
Store description of each component to the file _docs/02_components/[##]_[component_name]/[##]._component_[component_name].md with the next structure:
1. High-level overview
- Purpose: A concise summary of what this component does and its role in the larger system.
- Architectural Pattern: Identify the design patterns used (e.g., Singleton, Observer, Factory).
2. Logic & Architecture
- Control Flow Diagram:
- Generate a graph TD or sequenceDiagram in Mermaid syntax.
- Generate draw.io components diagram shows relations between components.
3. API Reference. Create a table for eac function or method with the next columns:
- Name
- Description
- Input
- Output
- Description of input and output data in case if it is not obvious
- Test cases which could be for the method
4. Implementation Details
- Algorithmic Complexity: Analyze Time (Big O) and Space complexity for critical methods.
- State Management: Explain how this component handles state (local vs. global).
- Dependencies: List key external libraries and their purpose here.
5. Tests
- Integration tests for the component if needed.
- Non-functional tests for the component if needed.
6. Extensions and Helpers
- Store Extensions and Helpers to support functionality across multiple components to a separate folder _docs/02_components/helpers.
7. Caveats & Edge Cases
- Known limitations
- Potential race conditions
- Potential performance bottlenecks.
Notes
- Strongly follow Single Responsibility Principle during creation of components.
- Follow dumb code - smart data principle. Do not overcomplicate
- Components should be semantically coherents. Do not spread similar functionality across multiple components
- Do not put any code yet, only names, input and output.
- Ask as many questions as possible to clarify all uncertainties.