Business Technology

Enforcing DDD

So you’re all excited about TDD by now. You’ve also hooked into DDD and cutting your teeth on some of the more progressive methods for delivering software accurately, and, fairly rapidly. And with time, you probably need to start leading a team in DDD. Or you just need to interface with a team but want to make sure everyone’s on the same page. That is, the last thing you need is DDD-mutiny…. 🙂

We were putting the domain together and started adding in the NHibernate mapping files. One of the many beautiful things about NH is the ability to generate the schema based on the mapping file data. Now, strictly speaking, the database is not all that important from a design perspective. At least, that is, not initially if you try remain true to your DDD-allegiance. Anyway, this post is not about all that. This post is about enforcing DDD and one of the things you might want to do is remove the temptation to do some fundamental ERD analysis during the domain design. And if you don’t want to, then don’t 🙂

So how’s this for aggressive and extreme?

<?xml version="1.0" encoding="utf-8" ?>

<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2">

    <class name="NHibernate.Examples.QuickStart.User, NHibernate.Examples" table="[2239987-9382WED-23D23]">

        <id name="Id" column="[LKJDSA-98DSJHDS-9D76SD]" type="String" length="20">

            <generator class="assigned" />


        <property name="UserName" column="[130SF98-08JDY-98BNXDS]" type="String" length="40"/>

        <property name="Password" column="[10DDD398-08EFHJDY-98CVBDDS]" type="String" length="20"/>

        <property name="EmailAddress" column="[1098-0KHS8JDY-98DDDS]" type="String" length="40"/>

        <property name="LastLogon" column="[10998HG-08JDY-98DS]" type="DateTime"/>



You get the idea? And replace those funny column/table names with GUIDs for extra spice. Or even better, random base64-encoded strings. Of course, you can write a script to generate random table and column names for all your mapping files in a release build if you’re not comfortable with the idea of a “random” database schema during development.

Imagine trying to decipher the following while debugging:
select KJHDSA-AS878, SL-983LD23-2J FROM ASLKAJS8-32JH INNER JOIN ASLOE-876-35 ON DAS-3FE-43 = 321JDH-8786 WHERE ALOYWI-9876D = 2

For me, the bigger question would be: why are you trying to debug the SQL when you’re effectively abstracting that part of the solution and ‘supposed’ to be treating it like a black box?

But before anyone gets me (too) wrong, I’m not suggesting this as a standard practice, just a far-out idea which opens up some possibilities for managing DDD adoption 🙂