> Markdown version of [/videos/100325-building-moduliths-that-last-patterns-for-sustainable-module-integration](https://www.wearedevelopers.com/videos/100325-building-moduliths-that-last-patterns-for-sustainable-module-integration). Every page supports `.md` or `Accept: text/markdown`. Links point to the HTML versions so they work for humans too. Agent guide: [/agents.md](https://www.wearedevelopers.com/agents.md).

---

# Building Moduliths That Last: Patterns for Sustainable Module Integration

Are shared database schemas turning your backend into a big ball of mud? Discover resilient integration patterns to build a modular monolith that actually lasts.

- **Speakers:** [Christoph Kober](https://www.wearedevelopers.com/@christoph-kober)
- **Event:** World Congress 2026 Europe
- **Published:** July 10, 2026
- **Duration:** 29:29
- **URL:** https://www.wearedevelopers.com/videos/100325-building-moduliths-that-last-patterns-for-sustainable-module-integration

## Summary

The tech industry's pivot back to modular monoliths (moduliths) from microservices aims to reduce operational deployment complexity, but these systems inevitably risk degrading into "Big Balls of Mud" without disciplined architectural boundaries. The foundational "rule zero" of sustainable moduliths is database modularity—relying on a shared schema defeats code-level separation of concerns and leads to tangled backends over time. With persistence boundaries secured, the structural integrity of the codebase depends entirely on selecting the right integration patterns between isolated domains.

Codebases should predictably evolve from simple direct module-to-module calls toward more durable, decoupled boundaries. Introducing Facades and the Mediator pattern establishes explicit contracts, routing commands while concealing module internals. As business complexity grows, architects can lean on Orchestration layers or SOA-style Process Engines (like BPMN) for end-to-end visibility and strong consistency. However, developers must actively prevent business logic from creeping into these layers to avoid creating "anemic modules." For sequential, pipeline-style domains, event-driven integration maximizes evolvability, allowing new domain functionalities to organically subscribe to published facts.

Not all cross-domain data needs to merge in the backend. Borrowing concepts from Self-Contained Systems, developers can lean on UI integration—using hyperlinks and dynamic includes to weave read-only views together directly in the browser. Ultimately, building a resilient modulith defies the "Highlander Principle"; there is no single best integration pattern. Architects should let their specific domain guide design choices, isolate event sourcing payloads from integration events, and prioritize explicit contracts early so that transitioning between architectural patterns remains just a routine refactor away.

**Keywords:** modulith architecture, domain-driven design, database modularization, facade pattern, mediator pattern, workflow orchestration, BPMN process engines, event-driven integration, event sourcing boundaries, anemic domain models, self-contained systems, UI integration, explicit contracts, pipeline domains, legacy modernization

## Chapters

1. **The challenge of preventing modular monoliths from degrading** (00:16) — Why initially well-structured monolithic applications often collapse into unmaintainable architectures over time.
1. **Rule zero requires strict database schema separation** (02:51) — Why sharing a single persistent database schema undermines software architecture despite modularization efforts on the code level.
1. **Identifying tight coupling from direct module calls** (04:41) — An example application demonstrates how implicitly coupled elements leak internal logic and create structural rigidity.
1. **Using facade patterns to define explicit modular boundaries** (07:58) — Refactoring direct cross-module connections into explicit facades simplifies integration intent and reduces tightly linked code.
1. **Decoupling direct connections using the mediator pattern** (09:01) — Implementing an intercepting mediator routes module commands without revealing inner dependencies or operational details.
1. **Extracting business logic into an orchestration layer** (10:29) — Separating peer-to-peer relationships into a centralized coordinator clarifies long-running procedural workflows and standardizes data consistency.
1. **Visualizing technical integrations with standalone process engines** (14:52) — Adopting visual process engines abstracts away complex technical execution details but risks relocating critical business rules.
1. **Integrating changing module states via domain events** (17:27) — Using an asynchronous in-memory event stream establishes strongly isolated and highly evolvable module interactions.
1. **Solving display requirements through user interface combinations** (22:22) — Combining module elements via explicit hyperlinks and dynamic templates prevents unnecessary backend events while advancing self-contained architectures.
1. **Choosing optimal integration patterns for domain modularity** (26:31) — Practical heuristics detail how mixing explicit software contracts supports domain-specific capabilities rather than rigidly mandating a single architectural trend.

## Related Moments

- [Rejecting unnecessary industry buzzwords and binary architectural thinking](https://www.wearedevelopers.com/videos/1827-mastering-modern-architecture-oliver-sturm) (from "Mastering Modern Architecture - Oliver Sturm")
- [Restructuring the monolith using domain-driven design](https://www.wearedevelopers.com/videos/1206-single-server-global-reach-running-a-worldwide-marketplace-on-bare-metal-in-a-cloud-dominated-world) (from "Single Server, Global Reach: Running a Worldwide Marketplace on Bare Metal in a Cloud-Dominated World")
- [Balancing modularization fundamentals with effective software engineering organization design](https://www.wearedevelopers.com/videos/970-microservices-monoliths-an-annoying-discussion) (from "Microservices? Monoliths? An Annoying Discussion!")
- [Prioritizing modularity over the monolith versus microservices debate](https://www.wearedevelopers.com/videos/164-monoliths-a-love-story) (from "Monoliths: A love story")
- [Defining the modulith approach for single deployment units](https://www.wearedevelopers.com/videos/987-modulith-instead-of-monolith-pragmatically-towards-microservices) (from "Modulith Instead of Monolith - Pragmatically Towards Microservices")
- [Fostering a continuous modularity mindset and observing industry trends](https://www.wearedevelopers.com/videos/1200-modularity-let-s-dig-deeper) (from "Modularity: Let's dig deeper")

## Related Articles

- [How to Avoid Over-Engineering](https://www.wearedevelopers.com/magazine/546-how-to-avoid-over-engineering)
- [Why Event-Driven Architecture Isn’t About Speed (and When You Actually Need It)](https://www.wearedevelopers.com/magazine/745-why-event-driven-architecture-isn-t-about-speed-and-when-you-actually-need-it)
- [MLops – Deploying, Maintaining And Evolving Machine Learning Models in Production](https://www.wearedevelopers.com/magazine/115-mlops-deploying-maintaining-and-evolving-machine-learning-models-in-production)
- [Why You Shouldn’t Build a Microservice Architecture](https://www.wearedevelopers.com/magazine/118-why-you-shouldn-t-build-a-microservice-architecture)

## Related Jobs

- [Software Solution Architekt](https://www.wearedevelopers.com/jobs/ext/1458613-software-solution-architekt) at **BWI GmbH**
- [Senior Backend Engineer (Java)](https://www.wearedevelopers.com/jobs/ext/19369-senior-backend-engineer-java) at **Bonial International GmbH**
- [Senior Backend Developer — AI: MCP & Agent Engine](https://www.wearedevelopers.com/jobs/48297-senior-backend-developer-ai-mcp-agent-engine) at **basebox GmbH**
- [Senior Engineer, Infrastructure Platform](https://www.wearedevelopers.com/jobs/ext/328836-senior-engineer-infrastructure-platform) at **Intercom, Inc.**
- [Senior Architect Realtime Bare-Metal Software](https://www.wearedevelopers.com/jobs/ext/381559-senior-architect-realtime-bare-metal-software) at **ZEISS Group**
- [Lead Solution Architekt - IT Service Management](https://www.wearedevelopers.com/jobs/ext/395627-lead-solution-architekt-it-service-management) at **BWI GmbH**