# 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.