Modeling

The Domain Is the Center of Gravity

Software structure should be driven by the problem it solves, not by the frameworks or infrastructure it uses. When code structure mirrors the domain, requirements changes map naturally to code changes, new team members learn the system by reading it, and bugs cluster less.

Domain Knowledge Is Built, Not Given

Nobody hands you a finished model. You build it through conversation with the people who understand the problem deeply — product managers, operations staff, subject-matter experts, end users. This is iterative. Expect concepts to split, merge, and rename. This process is the design work, not overhead.

Make Implicit Concepts Explicit

When the team keeps talking about a concept that doesn't exist in the code, that's a design smell. When code is convoluted for no obvious technical reason, a missing concept is likely forcing workarounds. When experts describe the same thing differently, the resolution usually reveals something neither was naming. Surface these hidden concepts — in code, in documentation, in process.

Know What Has Identity and What Doesn't

Some things are tracked over time and distinguished from others with similar properties — a specific customer, a specific order. Some things are defined entirely by their attributes — an amount of money, an address. Recognizing which is which changes decisions about equality, mutability, and lifecycle. Default to the simpler option (no identity) when you can.

Model Refactoring Is Not Technical Refactoring

Clean code that models the wrong thing is worse than messy code that models the right thing. Technical refactoring improves code quality. Model refactoring changes the design based on new understanding. Both are necessary, but model refactoring has the higher return.