Skip to content

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