Interactive

What does one discount rule touch?

Business request: a new discount rule in the catalog. On paper: a day's work.

Architecture

Tightly coupled (2009)

Tightly coupled (2009): changing the discount rule The catalog module writes directly to the invoicing tables. The reporting module reads the same tables. Part of the discount logic lives in a JSF screen. The change touches all four parts. writes directly to reads the same tables part of the discount logic lives here Catalog module touched not touched Invoicing tables touched not touched Reporting module touched not touched JSF screen touched not touched Tightly coupled (2009): changing the discount rule The catalog module writes directly to the invoicing tables. The reporting module reads the same tables. Part of the discount logic lives in a JSF screen. The change touches all four parts. part of the discount logic lives here writes directly to reads the same tables JSF screen touched not touched Catalog module touched not touched Invoicing tables touched not touched Reporting module touched not touched
  1. Catalog module: the discount rule changes here. Touched.
  2. Invoicing tables: the catalog module writes directly to them. Touched.
  3. Reporting module: reads the same tables. Touched.
  4. JSF screen: part of the discount logic lives here. Touched.

Cost of this change

Press the button to make the change.

Parts touched
4 of 4
Testing
Regression test across the entire system
Release
Full release
Deployment
Overnight window

Clear module boundaries

Clear module boundaries: changing the discount rule The discount rule sits inside the catalog module. Invoicing, reporting and the JSF screen use the catalog's public interface. The change stays inside the catalog module, and the system is still one deployable. Catalog module touched not touched Invoicing module touched not touched Reporting module touched not touched JSF screen touched not touched Discount rule Public interface Clear module boundaries: changing the discount rule The discount rule sits inside the catalog module. Invoicing, reporting and the JSF screen use the catalog's public interface. The change stays inside the catalog module, and the system is still one deployable. Catalog module touched not touched Invoicing module touched not touched Reporting module touched not touched JSF screen touched not touched Discount rule Public interface
  1. Catalog module: holds the discount rule and offers a public interface. Touched.
  2. Invoicing module: uses the public interface. Not touched.
  3. Reporting module: uses the public interface. Not touched.
  4. JSF screen: uses the public interface. Not touched.

Cost of this change

Press the button to make the change.

Parts touched
1 of 4
Testing
The catalog module
Release
The catalog module
Deployment
Still one deployable, a smaller and lower-risk change

Same change: 4 of 4 parts touched vs 1 of 4.

Java is not what makes this change complex. You can create the same problem in any language.

Illustrative example from the article. A single deployable is not the problem; coupling is.

Not sure where the coupling sits in your own landscape? Ask for a second opinion on your architecture

Back to the article