Define how to treat Project model in the modular monolith

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: !124411 (comment 1441183122):

@fabiopitino:

I agree with you here! 👍 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. 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