Domain-Driven Development
Good software development starts with good business thinking. Just like sound accounting practices help you understand your finances, domain-driven development helps you build software that reflects how your organization actually works.
Build software that speaks your business language
When accountants talk about "revenue" and "expenses," everyone understands what they mean. The same clarity should exist in your software. Domain-driven development means building systems where the code uses the same words and concepts as your business—making it easier to verify accuracy, train new staff, and adapt to changing needs.
Like accounting, but for business processes
Double-entry bookkeeping ensures every transaction is recorded twice, creating checks and balances. Domain-driven development creates similar clarity by making business rules explicit in code, so everyone can see and verify how things work.
Why this matters
Accounting as a mental model
The best business practices have stood the test of time because they create shared understanding and accountability. Let's use accounting—something everyone understands—to explain how domain-driven development works.
In accounting
- Clear language
- Everyone knows what "accounts payable," "revenue," and "depreciation" mean. These terms have precise definitions.
- Structured records
- Every transaction is recorded in a standardized format with date, amount, account, and description.
- Audit trail
- You can trace every dollar from initial entry through final reports. Nothing is hidden.
- Checks and balances
- Double-entry bookkeeping means debits always equal credits, catching errors automatically.
In domain-driven development
- Ubiquitous language
- Software uses the exact same terms as your business: "Service," "FormResponse," "WorkflowInstance."
- Structured models
- Every business entity is defined with clear attributes and relationships, just like chart of accounts.
- Event log
- Every action is recorded with who did it, when, and why—creating accountability and traceability.
- Business rules as code
- Validation rules in software match policy rules in manuals, catching mistakes before they cause problems.
See your organization as a system
Just like a CFO uses financial reports to understand organizational health, domain-driven development gives you visibility into how work actually gets done. This isn't about micromanagement—it's about understanding the system so you can improve it.
Know where you are
Like checking your bank balance before making a purchase, situational awareness means understanding current state before making decisions.
- • How many permit applications are pending?
- • Which services have the longest wait times?
- • Where are customers getting stuck?
- • What's the current workload by team?
Understand the flow
Like following money through accounts, trace work through your organization to spot bottlenecks and inefficiencies.
- • Where does work queue up?
- • Which handoffs cause delays?
- • What causes rework or returns?
- • Are resources matched to demand?
Predict impacts
Like forecasting cash flow, use system understanding to anticipate how changes ripple through the organization.
- • If we add online filing, how does staffing change?
- • What happens if demand increases 20%?
- • Which processes depend on this system?
- • Where will budget cuts create backlogs?
Real example: Processing a business license
Without situational awareness: "Why does it take 6 weeks to get a license?"
With situational awareness: "Applications sit in intake for 2 weeks (understaffing), then legal review takes 3 days (normal), then inspection scheduling takes 2-3 weeks (seasonal demand spike), then final approval is same-day (automated). We need to hire temporary intake staff during peak season."
You can't fix what you can't see. Making work visible creates the foundation for improvement.
Everything connects to everything
Your organization isn't a collection of independent departments—it's an interconnected system. Like how a change in one account affects your balance sheet, changes in one process affect others. Systems thinking helps you see these connections.
The feedback loop principle
In accounting, you reconcile accounts regularly to catch errors early. In systems thinking, you create feedback loops so problems surface quickly and improvements compound over time.
flowchart LR
A[Action] --> B[Result]
B --> C[Measure]
C --> D[Learn]
D --> E[Adjust]
E --> A
style A fill:#e1f5fe
style C fill:#f3e5f5
style E fill:#e8f5e8
Positive feedback loops
Improvements that reinforce themselves, creating momentum.
- Better documentation → easier training → better service
- Faster response → higher satisfaction → more referrals
- Clear processes → fewer errors → more capacity
Negative feedback loops
Problems that compound, creating vicious cycles.
- High turnover → knowledge loss → more errors → burnout
- Unclear rules → inconsistent decisions → appeals → delays
- No capacity → rushed work → rework → less capacity
Think in systems
- Look upstream
- Problems in one area often originate elsewhere. Trace issues to their source.
- Look downstream
- Your improvements affect others. Consider ripple effects.
- Look for patterns
- Recurring problems signal systemic issues, not individual failures.
- Optimize the whole
- Local optimization can harm overall performance. Think end-to-end.
From principles to practice
Start with what you know
You don't need to understand everything before you start. Like starting a business with basic bookkeeping before hiring a CPA, begin with simple models and refine as you learn.
-
Name your core entities
What are the main "things" in your business? Services, applications, customers, permits?
-
Map the happy path
How should things work when everything goes right? Document the ideal flow.
-
Add real-world complexity
What actually happens? Exceptions, edge cases, and workarounds.
-
Measure and improve
Track how reality matches your model. Adjust based on evidence.
Make thinking explicit
Organizational knowledge lives in people's heads—until they leave. Domain models capture this knowledge in shared artifacts that outlast individual tenure.
From implicit to explicit
Before: "Talk to Sarah, she knows how it works"
Knowledge trapped in one person's experience
After: "Here's the process model, with notes from our retrospective"
Knowledge shared, documented, and improvable
When thinking is explicit, everyone can contribute to improving it. When it's implicit, only insiders can participate.
Track decisions like you track dollars
Financial accountability requires tracking every transaction. Operational accountability requires tracking every decision. Domain-driven development makes this natural and automatic.
Who did it?
Every action in the system is attributed to a person or role. Like signing checks, accountability requires identity.
- • Who approved this application?
- • Who changed this policy?
- • Who responded to this complaint?
- • Who authorized this exception?
When did it happen?
Timestamps create audit trails. Like transaction dates in accounting, timing reveals patterns and enables accountability.
- • How long did review take?
- • When was policy last updated?
- • What's our average response time?
- • Are we meeting SLAs?
Why was it done?
Context matters. Like memo fields in accounting entries, capturing rationale helps future decision-makers understand intent.
- • What was the business justification?
- • Which policy guided this decision?
- • What alternatives were considered?
- • What evidence informed the choice?
The event log: Your operational ledger
Just as your general ledger records financial transactions, an event log records operational actions. This creates transparency, enables audits, and helps you learn from experience.
What gets logged
- Workflow instance activated (service request started)
- Form submitted by citizen
- Application advanced to review stage
- Approval granted by manager
- Notification sent to applicant
- Process completed successfully
What you can learn
- Average time from submission to approval
- Which step causes the most delays
- Who handles the most volume
- When errors most commonly occur
- Which processes get abandoned
- Whether changes improved outcomes
Building blocks of domain-driven development
Core concepts
- Entities
- The main "things" in your business that have identity over time. Like accounts in accounting: they persist, change, and matter individually.
- Examples: Service, Application, Permit, Customer, Employee
- Value Objects
- Descriptive attributes that have no independent identity. Like dollar amounts: $100 is $100, regardless of which account holds it.
- Examples: Address, DateRange, Status, Email
- Aggregates
- Clusters of related entities that change together. Like a complete invoice with line items: they're updated as a unit to maintain consistency.
- Examples: WorkflowInstance (with FormResponses), ProcessModel (with Lanes and Nodes)
- Events
- Facts about what happened, recorded permanently. Like journal entries: they describe changes but never get deleted or modified.
- Examples: ApplicationSubmitted, ReviewCompleted, PermitIssued
In practice
Business license application process
Entities:
BusinessLicense, Applicant, Inspector, ReviewProcess
Value Objects:
BusinessAddress, LicenseType, InspectionDate, FeeAmount
Aggregate:
LicenseApplication (includes all forms, documents, fees, inspections, approvals)
Events:
ApplicationSubmitted, DocumentsVerified, FeePaymentReceived, InspectionScheduled, InspectionPassed, LicenseIssued
Why this structure matters
- Everyone understands what a "LicenseApplication" is
- All related information stays together and consistent
- Complete history of every application is preserved
- Business rules are enforced automatically
- Changes are traceable and auditable
Start with good business practices
Domain-driven development isn't about technology—it's about bringing the same discipline to operations that you bring to finance. Clear language, structured thinking, accountability, and continuous improvement.
When software speaks your business language, everyone can participate in making it better. When processes are visible, everyone can see how to improve them. When actions are logged, everyone can learn from experience.
Learn by doing
See domain-driven development in action with Touchpoints' process modeling and workflow features.
How Touchpoints works