Question

I have been reading this ebook about DDD and it says that only highly complex systems are suited for DDD architecture. This leads me to second guess my decision to move more towards DDD as my architecture.

I am converting a classic ASP application over to .NET section by section. It includes a robust product categorization scheme and shopping cart which gets ~100-200 orders per day, and a video section similar to YouTube (videos and social features like rating, commenting, etc.). Since I have converted it into chunks, I want to treat each area of the site as a separate project.

The site continuously gets new features and needs to be easy to maintain and update.

Right now I am just using a basic homemade ADO.NET DAL with BLL and DTOs that act as a common layer.

Would it be better to go with a different architecture than DDD for this project? I am new to architecture and want to use some sort of pattern as a guide that I can follow throughout the conversion process to avoid the dreaded spaghetti anti-pattern.

If not DDD, then what? Still trying to find a good direction. It needs to be fast and easy for me to get started without being a complete expert as I am still learning.

Answer 1

DDD is not an architecture.

It’s a philosophy of design, you cannot just rename all your FooDAO’s to FooRepositiories, throw in an Anti-Corruption Layer and call it DDD.

It stands for Domain Driven Design. It puts a focus on the models that you use to solve problems in your specific domain. What Eric Evans is suggesting is that if your site is simply a form to join a mailing list there’s no reason to spend days in front of whiteboard playing with models. It’s my opinion if there’s only a single context in your domain you don’t need DDD. More on that in a bit.

There’s a famous quote:

“There are only two hard problems in Computer Science: cache invalidation and naming things.” — Phil Karlton

And DDD does have patterns to address these. It offers ubitiquous language as pattern to tackle naming, and it offers the oft misunderstood collection of patterns: Repository, Aggregate, Entity, and Value Object to tackle model consistency (which I will lump cache invalidation into and won’t cover further here).

But I would say most importantly it adds a critical 3rd item (not off by 1 problems):

Where to put stuff

Where to put code and logic. For me, the most fundamental concept in DDD is that of context. Not all problems are best served by the same model, and knowing where one context ends and another begins is a critical first step in DDD.

For instance, at my company we work with Jobs, Jobseekers and Recruiters. The world of a jobseeker is very different from the world of a recruiter and they both look at a Job differently. As an example, In the world (context) of Recruiters they can post a job and say

I want to make this job available in New York, Austin, and San Fran.

In OO speak: One Job has one or many Locations.

In the world of the jobseeker a job in LA is not the same job as a job in Boston. Nevermind if they are the same position at the same company. The difference in physical location is meaningful to the the jobseeker. While the recruiter wants to manage all Widget Manager jobs from a single place even if they are spread out around the country, a Jobseeker in New York does not care if the same position is also available in Seattle.

So the question is? How many Locations should a Job have? One or Many?

The DDD answer is both. If you’re in the context of jobseeker then a job has only one location, and if you’re a recruiter in that context a job can have many locations.

The Jobseeker context is wholly separate from the Recruiter Context and they should not necessarily share the same model. Even if in the end of the day all the jobs end up in the same DB (another context itself perhaps), sharing models between contexts can make a model a jack of all trades and master of none.

Now this example is very specific to the Domain of recruitment and jobseeking. It has nothing to do with Entity Framework of ADO or MVC or ASP. DDD is framework agnostic.

And it is DDD heresy to claim that framework A or B makes your architecture DDD. The whole point of DDD is that a model should serve the needs of a specific Context within a particular Domain. Frameworks can only support that and make it possible, they cannot do:

$ dddonrails new MyDDDApplication
$ dddonrails generate context ContextA
$ dddonrails generate context ContextB
$ dddonrails generate model Widget ContextA
$ dddonrails generate model Widget ContextB
$ dddonrails start

To specifically address the question, “To DDD? Or not to DDD?” The good news is you don’t have to decide at the onset, “This is going to be a DDD project!” DDD requires no toolset other than the willingness to think hard about the problems you’re trying to solve and ask is my code helping or hurting me?

The bad news is DDD requires a serious commitment to look at and challenge your design, asking every day “Is this model making the problems in this context as easy as possible?”

But separate the somewhat tactical and practical concerns of what presentation framework (MVC or no MVC) and persistence framework (Entity Framework?) from the task of modeling your business domain. If you want to start now, think about what contexts are in your app. Some questions to ask:

• Are multiple areas of the application solving different problems with the same basic data?
• How many teams work on the app?
• How do they integrate with each other?

Mapping these out is called Drawing a Context Map and it’s an important first step to starting to do DDD.

I encourage you to checkout the ddd website for more. There’s some good eric evans videos on qcon too. You may also want to read the Eric Evans’ book Domain Driven Design, he has many more examples.