liveBook · Manning

Module

As explained in Simple Object-Oriented Design: Create clean, maintainable applications

A module is a separately organized application unit containing its own domain model and related components.

A module is a separately organized application unit that owns a coherent business domain and hides its internal model, rules, and implementation behind an interface. Its purpose is to control complexity as systems grow: clients collaborate through a small contract instead of learning the whole domain. A deep module delivers substantial functionality through a simple API; a shallow one exposes nearly as much complexity as it contains. section 1.2.6 section 7.1

Figure 7.1 Modules should offer a simple API on top of complex features.

A deep module concentrates complex capabilities behind a thin API layer, so consumers depend on the contract rather than its internal machinery. section 7.1

Design modules to reduce the cost and reach of change:

  • Align a module with a business domain. A new invoice rule should primarily change the Invoice module, not Delivery. section 7.1.1
  • Keep components that routinely change together in the same module, where shared builds and tests can reveal incompatible changes. section 7.1.3
  • Expose an interface that is easy to use and does not reveal whether work uses a database, cache, or another module. section 7.2.1
  • Keep public contracts stable and backward compatible when independently maintained clients cannot update in lockstep. section 7.2.2
  • Offer extension points when customization is expected, but avoid abstracting every current company-specific decision. section 7.2.3 section 7.2.4

Billing, delivery, and inventory

An e-commerce system can place charging and invoices in Billing, shipment rules in Delivery, and stock decisions in Inventory. Delivery consults Inventory before shipping, while Billing notifies Delivery when an invoice is paid. Each collaboration needs a clear contract, allowing a team to improve one module without automatically forcing changes through the others. section 7.0 section 7.1

Modularization is not permission to create countless tiny units. Watch the dependency web: coupling to another module’s internal classes makes internal refactoring dangerous, expands the impact of changes, and can lengthen builds. Document the supported API, keep clients away from leaked details, and use architectural constraints where appropriate. Good boundaries are practical choices that must be monitored and improved over time. section 7.3 section 7.3.2 section 7.3.3

How Simple Object-Oriented Design: Create clean, maintainable applications covers it

How deep it goes
Develops domain boundaries, interface design, compatibility, extension points, and dependency monitoring without prescribing one architecture.
Examples
Uses Billing, Delivery, Inventory, Invoice, caching, registration APIs, and JUnit internal-class coupling as concrete cases.
What it assumes
Builds on object-oriented design, abstractions, and extension points before applying them across components.
What you can do after
Evaluate/understand module designs by checking domain ownership, API simplicity, client coupling, compatibility, and dependency growth.
How it connects
Connects modularization with encapsulation, information hiding, backward compatibility, extension points, Clean Architecture, Hexagonal Architecture, and Domain-Driven Design.
Cover of Simple Object-Oriented Design: Create clean, maintainable applications
liveBookmanning.com
Read Simple Object-Oriented Design: Create clean, maintainable applications on liveBook Get the book at manning.com

Also explained in

Compare how 35 books explain module →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Simple Object-Oriented Design: Create clean, maintainable applications. The section links point to the parts of the book it draws on.