|
|
|  |
 |
Better Software Home > In This Issue > Featured Article
|
 | |
2010 | |
 |
|
Domain-Centric Programming
by J.B. Rainsberger
Copernicus was the man who challenged the long-standing belief that the Earth was the center of the universe
Copernicus was the man who challenged the long-standing belief that the Earth was the center of the universe. Nearly five hundred years later, I challenged my own organization’s belief that the database is the center of the universe. Perhaps it is absurd of me to make such a grandiose comparison, but trying to talk people out of their longstanding beliefs is difficult, no matter how insignificant those beliefs may be "in the grand scheme of things."
In the Beginning
Early in my career as a programmer, I did as I was instructed. Someone gave me a feature to implement and the database schema to support it—they didn’t trust me to design a database table back then. I analyzed the feature and the schema, then set about figuring out how to implement the feature using that schema. Each time I tried, I failed. Inevitably, I needed to change the schema in order to implement the feature. Over time, I noticed a pattern: Whoever designed the database schema did so before having all the information they needed about the feature I was supposed to build. As a result, they designed the wrong database schema—their design might have been appropriate for other features, but not for the one I needed to build. Somewhere along the way, we were doing something wrong.
As time went on, my managers began to trust me to create and manage my own small slice of the database. It was at this time that I was introduced to the Change Control Board, an instance of the "best practice" that Steve McConnell describes in his book Rapid Development. The role of the Change Control Board was, it seemed to me, to reject changes to the overall product database schema. I admit that this was a rather juvenile way to put it, but with all the stories people had told me, that was the most logical conclusion I could reach at the time. As I began submitting changes to the Change Control Board, I realized that its function was not to reject changes, but rather to make programmers feel bad about asking for changes. It was tough love. Although they would ultimately feel trapped into approving my request for change, the board members would berate me for not getting it right in the first place. Apparently "good" programmers get it right the first time.
The Age of Enlightenment
I wanted to work better, both by leveraging existing solutions to common problems and by understanding how to test my code. I introduced myself to test-first programming (as it was known at the time) and the book The Pragmatic Programmer. I read about design patterns and learned about the magic of abstract classes and interfaces. I experimented with the Java testing framework (JUnit) and learned that loosely coupled components are easier to test. I read about separating abstractions from data and programming to interfaces. I began to understand what these people were telling me. And then it hit me just as surely as if it were a physical punch in the mouth: Perhaps the database is not the center of the universe.
I realized that if I could build my features without involving the database, then I could minimize the degree to which I would disrupt the Change Control Board. I could get the domain model right first, then implement a database schema that supported it well. No more guesswork; no more walking into that weekly meeting to feel bad about my inability to get it right the first time. It really seemed as if this could work. By designing the domain model first, I could minimize the impact of my work on the rest of the product without having to get everything right the first time.
Before testing my hypothesis, I considered just what it might mean if I were right. First, I could avoid costly database changes. Typically, the Change Control Board might discuss each change for a good fifteen minutes before coming to a decision. This discussion involved several board members, any interested managers, and often the programmer requesting the change, so the cost in salaries alone had to be pretty high. Then, there were the hidden costs: Sometimes I had to wait five business days for the testing group to see my database changes; sometimes my changes were "lost in translation" between modeling tools and SQL, resulting in "transcription errors" that led to phantom defects. Because changes were so costly, it just made sense to get the database schema right the first time. I confidently decided to test my hypothesis by designing the database schema last.
Enlightenment Meets Skepticism
I built a component entirely decoupled from its persistence mechanism: pure business logic that operated on Java objects without regard for how someone might store those objects on disk. It was the first time that I had written code that felt truly object oriented. This domain-centered approach to implementing business logic led me to ignore data persistence altogether. By "freeze minus three weeks," I had completely built and programmer-tested all the business logic I needed. Since this logic did not know anything about persistence, it was easy to add that feature at the end. The last thing I did was to build a simple, four-table database schema and a small component that read from and wrote to the live database. Since I had practiced test-driven development (as it is now known), I had high confidence that I had implemented everything correctly. Since I had focused on the domain, rather than the database, I was even more confident that I had gotten the database right the first time. My calm assurance was in stark contrast to what I saw around me.
As one might expect, during the three weeks before code freeze, teams were continually submitting schema changes to the Change Control Board. The tension mounted as everyone’s changes converged on the final schema. It had been my intention not to contribute to that tension, but rather to avoid it altogether. I felt that this was best for the organization, so it wasn’t until the third-to-last Change Control Board meeting before the freeze date that I submitted my request for new database tables. The Board wasn’t pleased.
The Change Control Board members admonished me for asking for changes "awfully late in the cycle." Worse, they said, I had built an entire feature set without first having the database schema approved! I had been prepared for this criticism and stated with supreme confidence, "To compensate you for this late change request, I promise not to make any other change requests for the rest of the release." I do not know whether anyone believed me, but at any rate the Board felt that it had little choice: without the schema I proposed, there was no way to ship my feature set. Reluctantly, and perhaps a touch angrily, they agreed.
A Brave New World
As I promised, I changed absolutely no part of that database schema. While other groups scrambled to make last-minute changes, I sat back, relaxed, and grinned. While they scrambled to fix defects coming from the testing group, I handled my lone reported defect, a misunderstood requirement. I managed to disrupt the Change Control Board, and indeed the rest of the (rather large) product team, a total of one time, which I imagine was a record at that time. I showed myself that the database is not the center of the universe by using two techniques: test-driven development and domain-driven design. Perhaps there are some skeptics out there who are still clinging to the belief that the database is the center of the universe, but I imagine it is just a matter of time before they realize that it is the domain, and not the database, that matters most. {end}
J.B. (Joe) Rainsberger is the founder of Diaspar Software Services, an author, speaker, programmer, teacher, mentor, and host to agile developers from around the world.
|
| | |
