DIGNALEGI

The reading room · Digna Legi

Using anti-requirements to find system boundaries • Particular Software

A personal relevance score

80–100: high value. 70–79: worth the time. Below 70: below the usual publication threshold.

Evidence-reviewed score based on available publisher text. Evidence strongly supports the mechanism and examples, but does not show external validation or alternative modeling tradeoffs in depth.

Scores reflect one reader’s profile, not an objective quality rating. Best is a separate personal selection.

How scoring works →

This brief · about 3 min with detail

Original article ↗ · about 10 min (text estimate)

Why read this

Absurd fake rules between attributes can reveal whether business concepts truly belong together or sit in different model boundaries.

AI brief · Checked against source text

The main idea

The article argues that modeling software around business nouns can silently produce overcoupled entities, because attributes attached to the same noun may change for unrelated reasons. Anti-requirements test that coupling by inventing ridiculous rules between two attributes; if business experts reject the relationship as nonsensical, those attributes probably belong in different model boundaries. The payoff is autonomy: data that changes together can be owned, cached, discussed, and evolved together.

Some background helpful. Basic familiarity with domain modeling, services or microservices, caching, and web request handling.

Go a little deeper

Coupling hides in copied attributes

The shopping cart becomes brittle because it starts mirroring facts owned elsewhere: price, inventory, delivery estimates, names, and descriptions. Each copied value creates a synchronization obligation, and different update rules make the obligation worse. A lower price can simply flow through, but a higher price requires user acceptance. That means the cart is no longer just a convenient object; it is absorbing unrelated business responsibilities.

Ridicule is used as a boundary detector

The method is not to ask abstractly whether attributes belong together, but to pair them in a fake business rule and listen for disbelief. A product-name rule that changes price exposes weak coupling; price multiplied by quantity exposes real coupling. The important distinction is that association in speech is not the same as logical dependency in the model.

The same value can mean different things

The article’s sharpest distinction is that even a single attribute can fracture by context. Quantity is shared across Sales, Shipping, and Warehouse, but its meaning changes: revenue calculation, packing work, and stock reservation are different concerns. Treating one shared number as one shared concept can preserve superficial consistency while smuggling several domains into one place.

Recomposition is part of the design

Decomposition does not remove the user’s need to see a cart. The article proposes ViewModel composition: separate components fetch their own data for a route and contribute it to a combined view, while POST handlers send changes back to each component’s backend. This keeps the page unified without making the UI a new point of hidden coupling.

A case from the article

The shopping cart that disappears

The central case starts with a ShoppingCart entity containing items, price, quantity, and cart operations. As requirements arrive, the cart must track price changes, inventory, delivery estimates, names, and descriptions. Anti-requirements then separate attributes by real dependency, until the business noun no longer maps to a large aggregate; what remains is a CartId coordinating separate concerns.

How the case is made

The case is made through an extended shopping-cart design example, with practical decomposition and ViewModel composition as the proposed integration pattern.

Where the idea has limits

The author explicitly warns that apparently absurd links can reveal real business rules; inventory, price, shipping time, and quantity may be related in some contexts, so the test requires domain confirmation.

A question to take away · from Digna Legi

Which attributes in your current model share a noun but would fail an honest anti-requirement test?

What the original adds

The original adds implementation detail on composing decomposed services back into a page, including route-registered data providers, POST handlers, asynchronous messages, and storage choices such as relational databases, Redis, key-value stores, or CDN-hosted JSON.

About this brief

AI-written, then separately checked for source support, useful detail and clarity. The author’s claims and our editorial question are kept separate. The original remains the author’s work. How we select and summarise →

Digna legi. Worth reading.