diff options
Diffstat (limited to 'doc/architecture/blueprints/modular_monolith/index.md')
| -rw-r--r-- | doc/architecture/blueprints/modular_monolith/index.md | 21 |
1 files changed, 17 insertions, 4 deletions
diff --git a/doc/architecture/blueprints/modular_monolith/index.md b/doc/architecture/blueprints/modular_monolith/index.md index ef50be643a6..f1e6c119552 100644 --- a/doc/architecture/blueprints/modular_monolith/index.md +++ b/doc/architecture/blueprints/modular_monolith/index.md @@ -93,12 +93,11 @@ There are many aspects and details required to make modularization of our monolith successful. We will work on the aspects listed below, refine them, and add more important details as we move forward towards the goal: -1. [Deliver modularization proof-of-concepts that will deliver key insights](proof_of_concepts.md) -1. [Align modularization plans to the organizational structure](bounded_contexts.md) +1. [Deliver modularization proof-of-concepts that will deliver key insights](proof_of_concepts.md). +1. Align modularization plans to the organizational structure by [defining bounded contexts](bounded_contexts.md). +1. Separate domains into modules that will reflect organizational structure (TODO) 1. Start a training program for team members on how to work with decoupled domains (TODO) 1. Build tools that will make it easier to build decoupled domains through inversion of control (TODO) -1. Separate domains into modules that will reflect organizational structure (TODO) -1. Build necessary services to align frontend and backend modularization (TODO) 1. [Introduce hexagonal architecture within the monolith](hexagonal_monolith/index.md) 1. Introduce clean architecture with one-way-dependencies and host application (TODO) 1. Build abstractions that will make it possible to run and deploy domains separately (TODO) @@ -107,6 +106,20 @@ add more important details as we move forward towards the goal: In progress. +## Glossary + +- `modules` are Ruby modules and can be used to nest code hierarchically. +- `namespaces` are unique hierarchies of Ruby constants. For example, `Ci::` but also `Ci::JobArtifacts::` or `Ci::Pipeline::Chain::`. +- `packages` are Packwerk packages to group together related functionalities. These packages can be big or small depending on the design and architecture. Inside a package all constants (classes and modules) have the same namespace. For example: + - In a package `ci`, all the classes would be nested under `Ci::` namespace. There can be also nested namespaces like `Ci::PipelineProcessing::`. + - In a package `ci-pipeline_creation` all classes are nested under `Ci::PipelineCreation`, like `Ci::PipelineCreation::Chain::Command`. + - In a package `ci` a class named `MergeRequests::UpdateHeadPipelineService` would not be allowed because it would not match the package's namespace. + - This can be enforced easily with [Packwerk's based Rubocop Cops](https://github.com/rubyatscale/rubocop-packs/blob/main/lib/rubocop/cop/packs/root_namespace_is_pack_name.rb). +- `bounded context` is a top-level Packwerk package that represents a macro aspect of the domain. For example: `Ci::`, `MergeRequests::`, `Packages::`, etc. + - A bounded context is represented by a single Ruby module/namespace. For example, `Ci::` and not `Ci::JobArtifacts::`. + - A bounded context can be made of 1 or multiple Packwerk packages. Nested packages would be recommended if the domain is quite complex and we want to enforce privacy among all the implementation details. For example: `Ci::PipelineProcessing::` and `Ci::PipelineCreation::` could be separate packages of the same bounded context and expose their public API while keeping implementation details private. + - A new bounded context like `RemoteDevelopment::` can be represented a single package while large and complex bounded contexts like `Ci::` would need to be organized into smaller/nested packages. + ## References [List of references](references.md) |