- Split GitLab monolith into components
- Make it simple to build and use “Decoupled Services”
- Use nested structure to organize CI classes
- Create new models / classes within a module / namespace
- Make teams to be maintainers of their code
- Add backend guide for Dependency Injection
Gusto / RubyAtScale:
- RubyAtScale toolchain for modularization
- Gusto’s engineering blog
- Gradual modularization (successor to CBRA)
- Component-Based Rails Applications (“deprecated”)
- Shopify’s jurney to modularization
- Internal GitLab doc transcript of an AMA with a Shopify engineer
Domain-Driven Rails / Rails Event Store:
Rails Event Store is relevant because it is a mechanism to achieve many of the goals discussed here, and is based upon patterns used by Arkency to build production applications.
This doesn’t mean we need to use this specific framework or approach.
However, the general concepts of DDD/ES/CQRS are important and in some cases maybe necessary to achieve the goals of this blueprint, so it’s useful to have concrete production-proven implementations of those concepts to look at as an example.
An illustration of how an application can evolve from a small, unstructured app, through various stages including a modular well-structured monolith, all the way to a microservices architecture.
Includes discussion of why you might want to stop at various stages, and specifically the challenges/concerns with making the jump to microservices, and why sticking with a well-structured monolith may be preferable in many cases.