At Europoint, we spent the first weeks doing nothing but modeling. No code, no database schemas, no API contracts. Just whiteboards, domain experts, and hard questions about how payment orders actually move through the system.
Every engineer I've worked with who hasn't done this has eventually wished they had. The pressure to start writing code is real — stakeholders want to see progress, and a database schema feels like progress. It isn't. A schema you design without understanding the domain is a bet that your first guess about the domain is correct. It rarely is.
What Modeling Actually Means
Domain modeling in the DDD sense means finding the language of the business and encoding it into your code. Not translating business language into technical language — keeping it. The payment order in the code should be called a PaymentOrder, not a Transaction or a Record. The state transitions should be named what the business calls them: Submitted, UnderReview, Approved, Rejected — not status codes 1 through 4.
It means finding the aggregates: which objects change together, which have invariants that must always hold, which can be eventually consistent with each other. It means finding the bounded contexts: where does 'customer' mean one thing, and where does it mean something different? Those boundaries are where your service boundaries will eventually live.
The Cost Of Getting It Wrong
I've seen codebases where the domain model was designed by the wrong person — usually someone thinking in tables, not in business processes. The result is systems where adding a new business rule requires touching seven files, where the same concept is represented three different ways, where nobody is sure which object is the source of truth for a given piece of state.
Refactoring a wrong domain model in a production system is expensive. The model touches everything — APIs, event shapes, database schemas, integration contracts. Getting it right upfront is dramatically cheaper than fixing it later.
Practical Starting Points
Start with the domain events. Ask: what happens in this business? Not 'what data do we store?' but 'what occurs?' PaymentSubmitted, PaymentApproved, FraudFlagRaised. Events are verbs in the past tense. They're facts about the world the system cares about. Building your model around them forces you to think about state transitions, causality, and what actually matters to the business.
Then find who issues commands that cause those events. Then find the aggregates that enforce the rules. The structure emerges from the domain, not from the technology stack. The technology stack is the last decision you should make.