Decision Record for Modular C4G Design
Status
accepted
Context
Previous versions of the package were designed as a "proof-of-concept". Now that we have proven the basic hypothesis works, to continue development, the code must gain better structure. It is necessary to create controlled extension points and maintain a high level of test coverage.
Decision
Restructure tool using C4 model as such Link to diagram

Level 1 - System Context
The system represents a configuration management solution through Google Sheets with centralized storage. Developers and GD/Dev/QA teams work with configurations through the convenient Google Sheets interface, while the application automatically synchronizes and distributes these configurations.
Level 2 - Container
The architecture is built around C4GPackage as the central component that transforms configurations from Google Sheets into serialized files. CI/CD integration ensures deployment process automation, while the separation of package and serialized configurations allows independent management of logic and data.
Level 3 - Component
C4GPackage is divided into Core (processing and generation) and Runtime (execution) modules. Core handles Google Sheets parsing, DTO generation, and configuration serialization, while Runtime provides loading and usage of ready configurations in application runtime.
Level 4 - Code
The modular architecture of Core includes specialized components: API as a facade, separate modules for Google interaction, sheet parsing, code generation, and settings management. This ensures high cohesion within modules and loose coupling between them.
Consequences
This modular architecture will enable easier testing of individual components in isolation, reducing the complexity of unit tests and improving test coverage. Extension points become well-defined through module interfaces, facilitating future feature additions without breaking existing functionality. However, this restructuring will require significant refactoring effort and may temporarily slow development velocity. The increased number of modules and interfaces may also introduce additional complexity in dependency management and configuration.
See also
- Code Coverage Threshold in CI — automated enforcement of the coverage target in GitHub workflows