Is this really DDD?

Question

I am 80% sure I should not be asking this question because it might come across as negative and I mean no disrespect to anyone, especially the author of this book. I have seen several posts recommending this book and its companion project. I have not read the book, but I have spent a few hours today studying the project. And while it does look very complete, I am having a very hard time with how much the details of various things are scattered around. I am struggling in my own designs with how much I have to change if an entity changes, and this project does not make me very comfortable as a solution.

For example, there is a Employee object that inherits from a Person. Person has a constructor with first-name, last-name, etc. and therefore, so does Employee. Private to Employee are members for first name, last name, plus public properties for the same.

There is an EmployeeFactory that knows about both Employee and Person properties, as well as the SQL column names (to pull values from a reader).

There is an EmployeeRepository with unimplemented PersistNewItem and PersistUpdatedItem methods that I suspect, if implemented, would build SQL for INSERT and UPDATE statements like I see in CompanyRepository. These write the properties to strings to build the SQL.

There is a 'Data Contract' PersonContract with the same private members and public properties as Person, and an EmployeeContract that inherits from PersonContract like Employee does Person, with public properties mirroring the entities.

There is a static 'Converter' class with static methods that map entities to Contracts, including

EmployeeContract ToEmployeeContract(Employee employee)

which copies the fields from one to the other, including Person fields. There may be a companion method that goes the other way - not sure.

I think there are unit tests too.

In all I count 5-10 classes, methods, and constructors with detailed knowledge about entity properties. Perhaps they're auto-generated - not sure. If I needed to add a 'Salutation' or other property to Person, I would have to adjust all of these classes/methods? I'm sure I'd forget something.

Again, I mean no disrespect and this seems to be a very thorough, detailed example for the book. Is this how DDD is done?

Answer 1

DDD s new enough (at least in some senses) that it may be a little early to say exactly "how it's done." The idea's been around for a fair long while, though, although we didn't make up a cool name for it.

In any case, the short answer (IMAO) is "yes, but...." The idea of doing a domain-driven design is to model the domain very explicitly. What you're looking at is a domain model, which is to say an object-oriented model that describes the problem domain in the problem domain's language. The idea is that a domain model, since it models the "real world", is relatively insensitive to change, and also tends to localize change. So, if for example your idea of what an Employee is changes, perhaps by adding a mailing address as well as a physical address, then those changes would be relatively localized.

Once you have that model, though, you have what I maintain are architectural decisions still to be made. For example, you have the unimplemented persistence layer, which might indeed be simply construction of SQL. It could also be a Hibernate layer, or use Python pickling, or even be something wild like a Google AppEngine distributed table structure.

The thing is, those decisions are made separately, and with other rationales, than the domain modeling decisions.

Something I've experimented with to some good result is doing the domain model in Python and then building a simulator with it instead of implementing the final system. That makes for something the customer can experiment with, and also potentially allows you to make quantitative estimates about the things the final implementation must determine.

Answer 2

Domain Driven Design is really simple. It says: make your Model classes mirror the real world. So if you have Employees, have an Employee class and make sure it contains the properties that give it its 'Employee-ness'.

The question you are asking is NOT about DDD, but rather about class architecture in general. I think you're correct to question some of the decisions about the classes you're looking at, but it's not related to DDD specifically. It's more related to OOP programming design patterns in general.

Answer 3

to me, what makes DDD different from "mere" model-driven design is the notion of "aggregate roots", i.e. an application is only allowed to hold references to aggregate roots, and in general you will only have a repository for the aggregate root class, not the classes that the aggregate root uses

this cleans up the code considerably; the alternative is repositories for every model class, which is "merely" a layered design, not DDD