## Problem As we explore more the modular monolith architecture we need to decide how to treat common concepts like `Project`. A `Project` may be comprised of different facets depending on the bounded context. Should there be a `Projects::` bounded context to deal with all "project related stuff"? If so, where do we draw the line between what goes into `Projects::` and what goes into another bounded context? ## Context and background This issue is created from a conversation sparked in this thread: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/124411#note_1441183122: @fabiopitino: >>> I agree with you here! :thumbsup: however with `Projects::` bounded context I refer to both data and behavior related to projects. The fact that `Project` model is a [god class is a different problem](https://docs.gitlab.com/ee/development/software_design.html#taming-omniscient-classes). Definitely a lot of the model's data could be represented as specific implementation in various bounded context: `Ci::ProjectSettings`, `MergeRequests::ProjectSettings`, etc. Within a `Projects::` bounded context, assuming that `Project` class is stripped to its intrinsic attributes (name, path, description, namespace_id, etc.), there can be various classes: * `Projects::UpdateService` * `Projects::CreateService` * `Projects::TransferService` * `Projects::Project` * `Projects::Alias` (current `ProjectAlias` model) * `Projects::Topic` (existing today) * `Projects::ProjectPolicy` >>> @mkaeppler: >>> `Project` is not a bounded context IMO. It is the super-set of what a GitLab project conceptually represents across all bounded contexts. A bounded context would be: * CI/CD * Issue management * Sales * Import/export * ... A `Project` *can* exist within a bounded context, e.g.: * `Ci::Project` -- only contains those attributes relevant for CI/CD * `Issues::Project` -- only contains those attributes relevant for issue management >>>