decompose

The problem description

@_docs/00_problem/problem_description.md.

Data samples

Located here: @_docs/00_problem/input_data. They are for reference only, yet it is examples from the real data.

Restrictions for the input data

@_docs/00_problem/restrictions.md.

Acceptance criteria for the output of the system:

@_docs/00_problem/acceptance_criteria.md.

Existing solution:

@_docs/01_solution/solution_draft.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.

3.1 KiB Raw Blame History