I have never read Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans. I had only skimmed a few articles about it, which felt abstract and disconnected from actual programming. Even after revisiting some of the most popular DDD articles, I found many of them overly complex or exaggerated. HtDP clarified these ideas for me in a way that no article could.
Language Is a Tool, Not a Goal
Many beginners—including myself—start their programming journey by asking: "Which language should I learn?" Python? JavaScript? Go? This often leads to focusing on syntax over actual problem-solving—a distraction from what truly matters. What matters more is the thinking framework for using those tools to solve real problems.
Consider someone learning carpentry by mastering the use of saws, hammers, and planes without understanding construction principles or reading blueprints. They may cut wood neatly, but they will not be able to build a solid house. Programming works the same way: mastering a language first is not the best approach when learning to program.
The Often-Forgotten Order: Data → Program → Solution
Program design—but not programming—deserves the same role in a liberal-arts education as mathematics and language skills.
Just as in solving a math problem, we first identify what is given and what is being asked before attempting the solution. The same discipline applies in How to Design Programs. In math, this is known as structured problem solving; in HtDP, it is called systematic design thinking.
HtDP teaches something radical: before writing code, define your data (the "given"). This is not merely about specifying types like int or string; it is about understanding the structure of information in the domain and representing it in the chosen programming language. The order taught by HtDP is:
- Data Definition – What information are we dealing with? How does its structure reflect the real world?
- Program – How do we process or transform this information?
- Solution – The concrete implementation that solves the problem.
Notably, the first stage says nothing about programming languages. Its focus is understanding the domain itself.
Itemization: A Gateway to Semantics
One concept from HtDP is itemization. Initially, it seems simple—representing data that can take several possible values—but the deeper you study it, the more profound its implications.
How does itemization differ from enumeration? Enumeration is a closed, fixed list of values, such as days of the week. Itemization, on the other hand, is a way of representing all possible forms or cases of a data type, allowing programs to handle every scenario in the domain.
For example, consider an Order that can go through several states: Init, Delivered, Done, and Cancel. At first glance, one might treat these states as an enumeration—a simple list of possible values. However, when we apply itemization, we recognize that Cancel is not just another fixed value. It represents a branch in the domain where additional information might be required, such as who canceled the order, when, and why. Unlike Init or Done, which are straightforward, Cancel carries contextual data that cannot be captured by a simple enum.
This illustrates why itemization is more than a fixed list: it encourages us to model all variations and structures within the domain, ensuring our program can handle every case meaningfully. Enumeration is static; itemization is domain-aware and extensible, reflecting the real-world complexity of the system we are modeling.
Data Definition as a Bridge to the Domain
Well-defined data is not merely a technical concern; it captures the essence of the problem to be solved. We translate real-world concepts—with all their complexity and nuance—into structures that computers can understand and process.
This is precisely what DDD emphasizes: deep understanding of the domain, collaboration with domain experts, and creating models that reflect domain knowledge. HtDP introduces these principles at a fundamental level, long before the complexity of enterprise systems arises.
Returning to Fundamentals
My experience with HtDP reminded me of the often-overlooked power of foundational literature. How to Design Programs is not “old” or “theoretical.” It shapes thinking in a way that endures, regardless of programming languages or trendy frameworks.
Languages change, frameworks come and go, but the ability to understand a problem, define data precisely, and build elegant solutions—that is what distinguishes a good programmer from someone who merely writes code.
Start with the problem. Understand your domain. Carefully define and refine your data through itemization. Only then write your program. That is the lesson of HtDP, which, without realizing it, embodies the essence of Domain-Driven Design.
See you until the next discovery.
Top comments (0)