Oleksandr Bezdieniezhnykh
73cbe43397
add refactoring phase complete implementation phase fix wrong links and file names
4.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 - Security approach:
@_docs/00_problem/security_approach.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
Components Decomposition
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. API Reference. Create a table for each 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
3. 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.
- Error Handling: Define error handling strategy for this component.
4. Tests
- Integration tests for the component if needed.
- Non-functional tests for the component if needed.
5. Extensions and Helpers
- Store Extensions and Helpers to support functionality across multiple components to a separate folder _docs/02_components/helpers.
6. Caveats & Edge Cases
- Known limitations
- Potential race conditions
- Potential performance bottlenecks.
Dependency Graph
- Create component dependency graph showing implementation order
- Identify which components can be implemented in parallel
API Contracts
- Define interfaces/contracts between components
- Specify data formats exchanged
Logging Strategy
- Define global logging approach for the system
- Log levels, format, storage
For the whole system make these diagrams and store them to _docs/02_components:
Logic & Architecture
- Generate draw.io components diagrams shows relations between components.
- Make sure lines are not intersect each other, or at least try to minimize intersections.
- Group the semantically coherent components into the groups
- Leave enough space for the nice alignment of the components boxes
- Put external users of the system closer to those components' blocks they are using
- Generate a Mermaid Flowchart diagrams for each of the main control flows
- Create multiple flows system can operate, and generate a flowchart diagram per each flow
- Flows can relate to each other
Notes
- Strongly follow Single Responsibility Principle during creation of components.
- Follow dumb code - smart data principle. Do not overcomplicate
- Components should be semantically coherent. 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.