Domain-FIRST Design

I'm still working my way through Domain-Driven Design by Eric Evans. While the "captivation" factor has gone down, the "interest in subject matter" factor has gone WAY up.


I just read his chapter on Aggregates - twice. And I may go back and read other chapters again, too. There were two major revelations for me in the chapter on Aggregates.

The first was the subject matter of the chapter. It is a totally new concept to me. I had never really considered "partitioning" the domain model into regions of guaranteed logical integrity but between which the rules may be lazily enforced. I saw at once that this was both a very useful concept, but also very foreign to me, giving me my first reason to re-read the chapter.

But the most important revelation was that it finally dawned on me that he's not talking about domain-driven database schema. In my mind, he's talking about domain-first design.

I "cut my teeth" in fast-and-furious ASP-land. All I was doing for five years was designing small databases (less than ten tables), and exposing them through ASP pages. I always started with the database design, and my mind never strayed far from it. There was neither reason, application, nor time to do proper three-tiered or n-tiered design, since I was literally just binding controls to tables. I learned about three-tiered design during this time, and I tried more than once to apply it, but in my little databound world I couldn't make it fit.

Now, I'm in all-grown-up-.NET-land. Objects. Proper three-tiered design. But my databound mindset hasn't left me. When interviewing for my current contract, they asked how I'd approach designing an application. I answered honestly: I'd start with the database schema, and work my way up. Even five chapters into Domain-Driven Design I was thinking in terms of domain-driven database schema. When Evans talked about limiting certain relationships to one-way as a way to save work, I wondered what he was talking about - you could always join tables, regardless of which table's key you were selecting by. When Evans talked about Entity vs. Value objects, I struggled, thinking that Value objects would still need to be stored in a table, and making me wonder how you could tell the difference.

In the chapter on Aggregates, Evans finally broke through. The examples he gives are of multiple users of a large, distributed system comprised of objects in memory. And Evans specifically draws a contrast between handling update conflicts at the database level and at the domain-layer level. And that's when I got it. While I have ALWAYS designed my software starting with the database schema, Evans is trying with his book to give me a different starting point - the domain layer. He wants me to envision the ideal object model first, write it and unit test it, even before designing a database schema.

It will require discipline - real effort - to design anything without regard for database schema. To think in terms of objects and relationships, apart from tables and primary and foreign keys. I'm going to revisit the design I spent a week without kids hammering out at home. I may go back and re-read other chapters, this time applying them to object design instead of database design. And I'm going to grow as a developer, because I finally see the light.

Thank you Eric Evans!