Create Working Group to identify the bounded contexts of a modular monolith
Context
The proposal to split GitLab Rails monolith into a modular monolith describes in details why modularization is important for the current stage of the GitLab codebase.
In order to make progress towards a modularized monolith we first need to understand what are the modules and bounded-context that are present today in GitLab Rails monolith.
Problem
Today code is namespaced using Ruby namespaces but we don't have explicit rules or guidelines on how to organize code. New namespaces are constantly being created and often there is no need to since new concepts could be nested inside existing namespaces to better represent bounded contexts. As a consequence we often have similar namespaces to represent the same bounded context: for example Vulnerabilities::
and VulnerabilityFeedback::
. Some times namespaces should instead go into larger bounded contexts in order to become more clear: for example Timebox::
.
Because of that developers also end up asking the same questions all the time: "where should I put this new class?".
Goals
- Stop proliferation of new top-level namespaces without explicit reason. We want developers to instead reuse or, even better, merge top-level namespaces to create richer modules instead of shallow ones.
- Using the correct bounded contexts (top-level namespaces) would help breaking down the monolith into modules, understand dependencies and breakdown responsibilities.
Proposal
Create and coordinate a Working Group with representative (Senior+ engineer) of various GitLab stages to identify 50% of top-level bounded contexts.
This is an activity that would be a pre-requisite for the modular monolith initiative and especially addresses https://docs.gitlab.com/ee/architecture/blueprints/modular_monolith/bounded_contexts.html#2-identify-existing-bounded-contexts.
Output of the Working Group
- A published list of identified bounded contexts that acts as a documentation for developers.
- A simple process for creating/deleting/renaming bounded contexts, to allow the codebase evolve over time.
Follow-up actions
- Create a Rubocop Cop to enforce top-level namespaces using the list of identified bounded contexts. A new namespace must be either an existing one or one from the new list.