modular-monolith-architecturelisted

# Modular Monolith Architecture A **modular monolith** is one application divided into business modules with enforced boundaries. All modules are released together, but one module must not use another module's tables, repositories, or private methods. Apply the following review before choosing files, classes, or framework mechanisms. ## 1. Identify Bounded Contexts A **bounded context** is a boundary around one business purpose, its rules, and the data it controls. Examples include Orders, Inventory, and Billing. Identify contexts from business responsibilities, not existing folders or tables. Use a separate context when a capability has several of these signs: - A clear purpose, such as taking orders or controlling stock. - Its own rules and data, such as preventing reserved stock from exceeding available stock. - It changes independently for business reasons. For example, promotion rules can change without changing order fulfilment. Do not create one context per entity. `Order`, `OrderLine`, and `OrderStatus` belong together because they implement the same order lifecycle. ## 2. Assign One Owner Give every business rule and stored model one owning context. The owner is the only context that may change that data or decide whether a change is valid. An **invariant** is a rule that must remain true after every completed operation, such as “reserved quantity cannot exceed available stock.” Enforce it inside the context that owns the data protected by that rule. Two c