Architecture, Modularity and Reusability
Architecture, Modularity and Reusability
This domain tests whether you can draw boundaries that hold: modules that own their data, expose a contract and can be understood without reading everything else.
Core rules
- Split by business capability (Catalog, Orders, Payments), not by technical layer (Entities, Microflows, Pages). Layer modules force every change to touch every module.
- A module owns its domain model. Other modules talk to it through exposed microflows or published services, not by directly retrieving its entities.
- Module roles are the module's contract with the rest of the app: what a caller may do through the module.
- Dependencies must flow one way. Circular module dependencies are a design smell and make the modules impossible to extract or test alone.
- Reusable modules should be versioned and their public surface kept small - every exposed microflow is a promise you must keep across upgrades.
- Consistent naming prefixes (
ACT_,SUB_,VAL_,DS_) make the model navigable and are a cheap form of documentation.
Worked example
In an e-commerce app, Orders needs a payment authorisation. Instead of Orders reading PaymentTransaction entities directly, Payments exposes ACT_AuthorisePayment returning a result object. Orders depends on Payments; Payments knows nothing about Orders. When the payment provider changes, only the Payments module is touched, and Orders can be tested against a stub of the service microflow.
Traps
- A single
MyFirstModulethat becomes a god module holding everything. - Cross-module entity associations used as a shortcut instead of a service call.
- Duplicating an entity in two modules so both can 'own' it.
- Exposing whole entities as published services rather than a deliberate contract.