How To Share Code In Modular Monolith? Independent Implementation Overview

The Independent Implementation pattern occurs when multiple modules in a modular monolith develop similar functionality separately, without sharing code or creating dependencies between modules. Each module maintains its implementation of comparable (potential the same) business logic.

How To Share Code In Modular Monolith Architecture? Supporting Module Integration Pattern

The Supporting Module Pattern reduces duplication by extracting shared functionality into a dedicated module. It promotes modularity, decoupling, and team independence, but introduces trade-offs like potential coupling and complexity. Apply only with a clear need and ownership model.

Krzysztof Baranowski – Personal BlogKrzysztof Baranowski

A few rules are crucial to understand this article. You have to know that each pattern or approach is valid only in a specific context. You have to choose an approach suitable for your case, and it will never be ideal. It is always a trade-off.

In this pattern, Module A and Module B each implement their own version of similar behavior independently. There is no code sharing, no common interfaces, and no cross-module dependencies. Each module owns its complete implementation stack for the functionality in question.

When to Apply

This pattern is appropriate when:

• Module (and team) autonomy is prioritized.
• Coupling concerns outweigh duplication.
• Shared implementation would create unwanted coupling between modules.
• Teams have explicitly agreed that similar functionality should be developed separately.
• The team better positioned to share the logic prefers not to expose it due to stability concerns or to avoid becoming a service provider to other teams.
• Different stakeholders are defining requirements for each module, leading to parallel development (unconscious use of the pattern)*.
• The functionality serves different business contexts (different stakeholders) despite surface-level similarities.
• Modules evolve at different rates or have different non-functional requirements (related to previous point).
• Module (domain) boundaries are unclear or requirements are uncertain.
• Teams are unaware that similar functionality already exists elsewhere (unconscious use of the pattern).
• The cost of coordination and dependency management exceeds the cost of code duplication.

Trade-offs

Advantages:

• Complete team autonomy and independence
• No cross-team coordination overhead
• Each implementation can be optimized for specific domain needs
• Clear ownership boundaries
• Reduced risk of breaking changes affecting multiple modules

Disadvantages:

• Potential code duplication and maintenance overhead
• Potential inconsistency in behavior across modules
• Missed opportunities for reuse and standardization
• Higher development and testing effort
• Risk of solutions diverging over time

Implementation Guidelines

• Clearly document the decision to implement independently.
• Establish clear module boundaries to prevent accidental coupling.
• Consider periodic reviews to assess if the pattern still makes sense as the system evolves.
• Ensure each team has sufficient expertise to implement and maintain their version of potential sharable logic.
• Monitor for excessive divergence that might indicate need for alignment.

When to Reconsider?

This pattern may need reevaluation (in a context of potential sharable code) when:

• Maintenance costs become significant (assuming we are aware that more than one module need to maintenance, complex duplication).
• Inconsistencies create user experience problems.
• Business requirements begin to align (for more than one module). In conclusion, it doesn't make sense to maintain a few (the same) code bases that need to be developed at the same time and in the same way.
• Team structures or priorities change.
• The duplicated functionality becomes a core business differentiator requiring standardization.