Reminder: Architectural patterns for modular monoliths that enable fast flow

You are receiving this email because you subscribed to microservices.io

This month, I'm teaching an online public workshop Architecting for fast, sustainable flow: enabling DevOps and Team Topologies: 9am-11am CET/4pm-7pm Korea Time, September 23th-25th, 2024 20% discount for groups of 6 or more.

In November, I'll be teaching workshops in Berlin and Milan. If you would like me to visit your company for workshop or architecture review, please contact me.

In this article, I describe three architectural patterns for modular monoliths. These patterns are based on my experience developing both monoliths and microservices.

Designing monoliths for fast flow

The primary concerns when using the monolithic architecture pattern are:

• Managing the complexity of a large codebase
• Maximizing team autonomy despite the single code base
• Accelerating the single deployment pipeline in order to still provide fast feedback

There are three patterns that address these concerns:

• Modular monolith, aka. domain-oriented monolith
• Domain module API
• Domain API build module

Let’s first look at the modular monolith pattern.

Pattern: Modular monolith, aka. domain-oriented monolith

Organize a monolith as a collection of loosely coupled, domain modules that are based on DDD subdomains/bounded context rather than technical layers in order to manage complexity and improve team autonomy.

For more information, see The modular monolith, which introduces the basic idea, and No such thing as a modular monolith, which explains why the term ‘modular monolith’ is a misnomer.

Pattern: Domain module API

Encapsulate each domain module’s implementations details, which includes its database schema, behind a stable, facade-style API in order to reduce loose design-time coupling between modules and improve testability.

For more information, see Encapsulating the customers domain behind a facade.

Pattern: Domain API build module

Define a separate build module (e.g. Gradle subproject) for the domain module’s API, which the domain module’s clients depend upon (rather than the implementation), in order to reduce build-time coupling and accelerate the deployment pipeline.

For more information, see Using domain API modules to reduce build-time coupling.

Want to learn more

You will learn about these and other patterns in my Architecting for fast flow: enabling DevOps and Team Topologies workshop, 9am-11am CET/4pm-7pm Korea Time, September 23th-25th, 2024. 20% discount for groups of 6 or more.

Need help with accelerating software delivery?

I’m available to help your organization improve agility and competitiveness through better software architecture: training workshops, architecture reviews, etc.

Learn more about how I can help

Chris Richardson Consulting, Inc | 180 Rishell Drive, Oakland, CA 94619 Unsubscribe you Update Profile | Constant Contact Data Notice Sent by chris@chrisrichardson.net powered by Try email marketing for free today!