# 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
 - Store description of each component to the file `docs/02_components/[##]._[component_name]/[##]_spec_[component_name].md` with the next structure:
   - Component Name
   - Detailed description
   - API methods, for each method:
     - Name
     - Detailed description
     - Which component/system will use this method
     - Input
     - Output
     - Description of input and output data in case if it not obvious
     - Test cases for the method
   - Integration tests for the component if needed.
   - Non-functional tests for the component if needed.
 - Store Extensions and Helpers to support functionality across multiple components to a separate folder `docs/02_components/helpers`.
 - Generate draw.io components diagram shows relations between components. 

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