A Quiet Conversation about DDD and Data First Design

At the MVP Summit I had the pleasure to sit down at a party for some one on one time with Don Smith. I’m trying to think of my blog as a nice little corner to talk, rather than a soapbox. I want to make an share something that is not shouted from the rooftops. Eeegads, I don’t want to start another debate on this.

A few months ago, the EF team started a wiki where Ward Bell and I felt quite attacked for suggesting that DDD is not always the best approach. And thus, it is with some trepidation that I touch this topic. But today’s Database Weekly has a column on it and I really feel there’s stuff worth hearing. If you’re here in my nice intimate corner, you can hear it.

The question of whether to start with a database or a domain (business object) model makes no sense. The answer is easy: start with the one most likely to bring you success, and don’t ignore the impedance mismatch problem.

A well structured application has a good domain model and a good (relational) database and a good strategy to cross the impedance mismatch boundary. That boundary exists because neither the domain nor the database should drive the structure of the other.

A database might be a more successful starting point if you have good, stubborn, or available DBA’s or if your DBA’s are good analysts. If you’re a small shop – which do you build better and have you ever tried building it the other way? Database first is also often a good starting point if you have an existing database. Even if the database is bad, it contains the existing business, and it’s my belief we should never close our eyes to a way the business has already expressed itself if we can get a hold of it (it’s not in code). While we should consider available expressions of the business, we should not blindly accept any piece without exploring also exploring its problems.

A domain might be a more successful starting point if you have good, stubborn, or available coders, or if your coders are good analysts. If you’re a small shop – which do you build better and have you ever tried building it the other way? Domain first (DDD) can also be a good starting point if you have an existing database. If you build a domain model that you constantly validate against the existing database you can base your thinking on experience while not being stuck in that experience. While we should consider available expressions of the business, we should not blindly accept any piece without exploring also exploring its problems.

If it’s an even match, consider DDD. The issues are more subtle and getting them out of the way might be helpful to your project.

The monumental disservice that resulted from the EF wiki (which has thankfully now died a formal death) is that this decision appeared to be a religious one or one that marked you in one camp, or perhaps to some even something about your level of coding. All of that is stupid.

- Do DDD or database first based on what makes sense in your specific scenario

- Whichever way you start, attention to the impedance mismatch will minimize negative consequences to the other side of the boundary

It comes down to the obvious. It’s your team, it’s your project. Make decisions based on your reality, not dogma. Learn from the debates in our industry. Don’t pick sides and follow blindly (even my side.)

So, now we can go back to the rest of the party. If this kicks off another brawl, I suggest slipping out by the side door.

4 thoughts on “A Quiet Conversation about DDD and Data First Design”

  1. Let’s make a clarification of terminology briefly. Domain first and DDD are not the same thing. While I have done many projects with a model first approach, almost none of them would be considered DDD. DDD is most appropriate for complex projects. Hence the subtitle of Evan’s book “Tackling Complexity in the Heart of Software.” This is the mistake that many advocates of DDD make, they try and apply it to every problem, thus actually introducing complexity where there should be none. DDD aside, I do believe that a model first approach is the best way to solve a problem 90% of the time. I see the database as an infrastructure concern. ie. The database exists for the business, not the business for the database. If you buy this, it makes more sense to start by modeling the business concerns. These are very rarely handled by mere data, but usually involve a good amount of behavior. Now, here’s an interesting observation. If you design based on behavior, the right data will most certainly fall out naturally. If you design based on data, you may miss important behavior. However, if your system has little or no behavior, by all means start with the database. But, keep in mind the inadvertant coupling you may be creating with the infrastrucutre. This could cause you problems refactoring and evolving the application over time. And, if the application turns out to be truly complex, implementing DDD will be very difficult indeed. For me, its all about giving my application room to grow and starting with a the model first (DDD or not) generally results in an application design that makes this possible.

  2. Rob,

    Thanks for your comments. I’ve been in meetings with fairly savvy high end architects across multiple platforms deciding to play the idiot to try to get a distinction between DDD as domain first and DDD as presented in a set of patterns in Evan’s book. They made no distinction and gave me Evan’s book. I want to read it because an architect I respect refers to it as fragile for many scenarios. Once a friend of mine finishes reading it (I’m swamped for months here) I’ll be able to comment more intelligently.

    For now, in reading my post above, let me clarify, I mean domain first approach, which may or may not involve the patterns in Evan’s book.

    Kathleen

  3. I don’t know for sure which is better, but I would lean towards modeling the behaviors before I modeled data.

    When you are unsure of the relationships between things, you *will* create more complex data relationships than you know you need. Database complexity is reflected all the way up the levels of your application, often to the UI. That’s a heavy price to pay for a “what if”.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>