November 24, 2018

Domain Decomposition

  —It's a what changes together stays together world-view.

In Documenting Architecture Decisions I look at Ruth Malan’s 2017 Linda M. Northrop Software Architecture Award keynote. In this article, I take another look at Ruth’s keynote with a focus on the Big Ball of Mud. The theme in Ruth’s keynote is the notion that architecture embodies a set of decisions whose importance reflects the cost of change.

Ruth references an article by Bjørn Einar Bjartnes titled Undoing the harm of layers. Bjørn makes an argument for avoiding technology-oriented decomposition in favor of domain-oriented decomposition.

A technology-oriented decomposition manifests as having your top-level architecture devoid of domain concepts. This type of decomposition spreads domain concepts across different technologies instead of localizing them like you’d expect. This increases the number of modules to change when you update a domain concept.

Bjørn mentions the criteria used to decompose systems into modules:

… it is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart. We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others.

Bjørn sumarizes this as

what-changes-together-lives-together

A flowchart refers to a structured programming technique. Flowchart Techniques for Structured Programming was published in 1972, a year after Parnas’ paper. I assume Parnas was warning not to decompose systems using the process flow depicted in a flowchart. The process flow used to solve a problem doesn’t organize the solution using the structure of the domain. Your architecture should reflect the structure of the domain.