Seeing the Boat – Part 7: Unlocking the Hidden Power of Domain Knowledge
In the previous parts of this series, we've established development speed—valuable features delivered per developer per time unit—as the heartbeat of software quality, driven by the science-engineering cycle (A: domain understanding, B: simple OO implementation). We've explored coping vs. improving, resistance to change, and the pitfalls of enterprise frameworks. But today, let's address a subtle irony: Every application has a domain model—the essence of your business logic—but most teams aren't leveraging its full benefits because it's implicit and hidden. This leaves your system rowing like the Dutch boat: bloated and inefficient. An explicit model, however, turns it into the Japanese boat: lean, transparent, and continuously refined.
A domain model is the nature of your business logic—the rules, interactions, and behaviors that define "what" your software automates. In many applications, it's implicitly embedded: in the data model (e.g., table structures hinting at entities like orders or customers), in services or functional pipelines (where behavior is scattered across methods or transformations), or in CQRS setups (where separating reads and writes can fragment the domain unless anchored by a cohesive model). These approaches make the model intangible and non-transparent. Logically, if the domain isn't explicit, how can you evaluate its fit to the business? You can't test its "appropriateness" continuously, leading to misalignments that slow development speed over time—features take longer as code drifts from reality.
The drawbacks are clear. Without transparency, new developers onboard by reading vast amounts of code, piecing together the domain like a puzzle. This is inefficient: they learn the "how" (implementation mechanics) before the "what" (business essence), delaying contributions and risking errors. In contrast, an explicit domain model—crafted as cohesive objects (e.g., an Order with lifecycle methods like applyDiscount() or transitionToShipped())—makes the context plain and visible in code. The model becomes self-describing: objects encapsulate logic, relationships, and rules, allowing quick comprehension. For example, in a fraud detection system (as discussed in Part 6), Scenario objects expose fraud patterns overtly, so a new developer grasps the domain without digging through pipelines.
The real power lies in continuous evaluation and feedback. An explicit model invites scrutiny: Which object should own which logic? Does Order handle discounts, or should it delegate to a Billing aggregate? This exposure enables rapid testing of the model's fit to the business domain—domain experts can review and tweak it directly, fostering better, faster refinements. In implicit setups, evaluation is ad hoc or absent, as logic is buried. Explicit modeling amplifies this: By focusing on the "what" (domain actions), implementation becomes a secondary step, naturally simplifying the system. Feedback loops tighten—coding an object reveals gaps, refining the model and boosting speed (Part 2's cycle).
For larger applications, the benefits compound. Implicit models lead to "big balls of mud," where tangled services, pipelines, or purely relational schemas hide inefficiencies, forcing rebuilds (Part 3's coping). Explicit models scale by keeping logic traceable and tangible, enabling smaller teams, faster delivery, and more stable products (as per our discussions). And although OO is the most natural way to make the model explicit, the core principle isn’t language-bound—FP, relational, or CQRS systems can all benefit once they surface the domain as a first-class citizen. The point is not syntax, but explicitness.
Semantics matter here too (Part 5): Don’t let implicit models rob you of these advantages. Start explicit—model the domain first, and watch your boat glide.
