6.2. Structural Patterns

Once services exist, recurring structural problems — adding cross-cutting behavior without touching application code, proxying outbound calls, shielding new services from a legacy model — have named solutions that deploy as separate processes rather than shared libraries. This chapter covers the sidecar, ambassador, and adapter patterns, the anti-corruption layer that keeps a clean domain from being polluted by a legacy one, and the shared-library-versus-sidecar trade-off that decides how cross-cutting logic is distributed.

Topics Covered

• 6.2.1. The Sidecar Pattern: Covers the sidecar pattern, attaching cross-cutting behavior as a co-located process beside the main container.
• 6.2.2. The Ambassador Pattern: Helper Container as Proxy: Explains the ambassador pattern, a helper proxy that handles a service’s outbound network concerns.
• 6.2.3. The Adapter Pattern: Standardized Interfaces: Covers the adapter pattern that normalizes heterogeneous interfaces into a standardized one.
• 6.2.4. Anti-Corruption Layer (ACL): Integration with Legacy Systems: Explains the anti-corruption layer that shields a clean domain model from a legacy system’s concepts.
• 6.2.5. Shared Library vs. Sidecar: Dependency Management Trade-offs: Weighs the dependency-management trade-offs between a shared library and a sidecar for cross-cutting logic.