Model what remains stable
Start with the business as it works, including its decisions, meaningful events, rules, exceptions, and variations. The result is a technology-independent model of the domain.
Domain-Driven Architecture
Model what remains stable. Measure what will become limiting. Change before it constrains the business.
A practical approach to architecture that begins with the business process, directs automation toward measurable value, and evolves software when real operating thresholds demand it.
Follow the BookThe central idea
Architecture should begin with the business
Software architecture is often shaped by frameworks, platforms, and deployment models before the system's purpose and operating conditions are understood. Domain-Driven Architecture reverses that process.
Replace what does not
Algorithms, components, and infrastructure are implementations for a particular operating range. Preserve stable domain meaning while changing the implementation when business demand requires it.
The mindset
A continuous, evidence-informed loop
Architecture is not a one-time blueprint. It is a sequence of decisions made as the business and its constraints develop.
-
Model the stable process
Understand what happens manually, which decisions are made, and which rules must always hold.
-
Find high automation value
Automate the common, simple, valuable cases. Keep rare or ambiguous cases manual until that changes.
-
Define measurable thresholds
State the conditions under which the current implementation will no longer be good enough.
-
Observe the constraint
Measure where work accumulates, people wait, failures occur, or business growth is limited.
-
Predict when it will bind
Use forecasts, lead time, and a safety margin to determine when change must begin.
-
Change only what is necessary
Move the threshold beyond expected demand, verify the result, and begin the loop again.
Threshold hypothesisThis implementation works until X reaches Y.
Planning formulaLatest safe start = predicted threshold date − change lead time − safety margin.
Why it matters
Invest in architecture when it creates business value
Avoid premature complexity
Do not build for hypothetical scale or automate every exception before the demand exists.
Make trade-offs explicit
Connect architectural effort to measurable effects such as waiting time, error rate, manual workload, risk, or cost per case.
Change in time
Begin early enough to protect the business, but not so early that forecasts harden into unnecessary technology.
Keep domain meaning stable
Let language, rules, and events provide continuity while the mechanisms that implement them evolve.
A worked example
From capacity guess to a timely decision
Imagine a manual order process handling 50 orders per day. Observation and queue analysis suggest that 80 orders per day may be its safe limit. If demand grows by five orders per day each month, the team expects to reach that threshold in six months.
6 monthsuntil the threshold
−2 monthschange lead time
−1 monthsafety margin
=Month 3latest safe start
The response need not automate every order. If rules can safely handle the 80 percent of standard cases, 150 incoming orders would leave 30 for manual assessment. The team tests the smallest change that could create enough capacity while preserving human judgment for exceptions.
These figures are illustrative hypotheses, not universal limits. Real decisions require measured workload, case mix, uncertainty, and regular review.
The forthcoming book
Domain-Driven Architecture
The book turns this mindset into a practical process for making architectural decisions under real economic and operational constraints.
It is about learning how to:
- separate stable domain meaning from replaceable implementation;
- choose automation by value instead of coverage;
- form measurable threshold hypotheses;
- forecast when change should begin; and
- verify that a change actually moved the constraint.
Who this book is for
For people who must decide what to change, and when
Software architects
Decide which structural complexity is justified by real requirements and constraints.
Engineering leaders
Plan modernization and scaling work around evidence instead of urgency or fashion.
Product and business leaders
Connect software investment to demand, risk, customer outcomes, and business growth.
Software teams
Avoid both over-engineering too early and reacting only after an implementation has become a bottleneck.
About the author
Stefan Priebsch
Stefan is a software architect, trainer, author, speaker, and co-founder and CEO of The PHP Consulting Company. With more than three decades of experience helping teams improve software design and collaboration, he connects domain understanding, architectural decisions, and business outcomes.
Architecture is a business decision.