mirror of
https://github.com/azaion/gps-denied-desktop.git
synced 2026-04-22 11:06:36 +00:00
Oleksandr Bezdieniezhnykh
83 lines
4.1 KiB
Markdown
83 lines
4.1 KiB
Markdown
# 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.
|