Scott Hanselman

Hanselminutes Podcast 140 - Rob Conery learns about Domain Driven Design

December 05, 2008 Comment on this post [7] Posted in Podcast | Programming
Sponsored By

My one-hundred-and-fortieth podcast is up. Neither I nor Rob Conery are experts in DDD (Domain Driven Design.) We hear a lot about DDD, but we hear very "Zen-like" and "soft" terms. As concrete (or fairly so) thinkers, Rob and Scott try to get our tiny minds around DDD. Is it a fad? A religion? Some kind of software design cult? Rob Conery has decided to learn for himself, and I join him for the trip in this episode. We likely accomplished nothing, but we've taken the first step.

The premise of domain-driven design is two-fold:

  • For most software projects, the primary focus should be on the domain and domain logic; and
  • Complex domain designs should be based on a model.

Also, check out Eric Evans on .NET Rocks!

Subscribe: Subscribe to HanselminutesSubscribe to my Podcast in iTunes

Do also remember the complete archives are always up and they have PDF Transcripts, a little known feature that show up a few weeks after each show.

Telerik is our sponsor for this show!

Building quality software is never easy. It requires skills and imagination. We cannot promise to improve your skills, but when it comes to User Interface, we can provide the building blocks to take your application a step closer to your imagination. Explore the leading UI suites for ASP.NET and Windows Forms. Enjoy the versatility of our new-generation Reporting Tool. Dive into our online community. Visit

As I've said before this show comes to you with the audio expertise and stewardship of Carl Franklin. The name comes from Travis Illig, but the goal of the show is simple. Avoid wasting the listener's time. (and make the commute less boring)

Enjoy. Who knows what'll happen in the next show?

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Hosting By
Hosted in an Azure App Service
December 05, 2008 6:02
I love the intro where Rob says he is afraid of becoming the village idiot. Funny stuff : )
December 06, 2008 0:35
I've had similar challenges in learning DDD, but I don't work in consulting and don't do projects where I sit down with clients a lot, so my chance to actually practice it is limited. I still find it to be a fascinating subject and like hearing things like this where others explore it and bring more details to light. Too much jargon definitely obscures the message.
December 06, 2008 1:29
What I found interesting was the idea that DDD is potentially a new concept, although at times he said that it was coming full circle. Really, large programs have been using DDD since the beggining, and I do mean the begining.

The industry has tried to move away from having programers and architects know so much about the inner workings of the "business." Offshoring being the most extreme extension of the concept of seperation of concerns. I've heard explained that a programmer should concentrate soley on how to program. I've always argued that the best programers I know are extremely knowledgeable about business workflows.

For example, very large logistics systems have so many rules and regulations involved with seemingly simple transactions that you MUST have a domain expert to even consider the code. We have a name for them. FTE's and SMES. However, on good teams the functionals and subject matter experts have been working with the same developers so long that the business begins to imprint on the developer and they can converse openly in the native language of the logistician. The speed this allows during analysis and design is crucial.
December 08, 2008 12:09
Interesting listening.

The easiest way to understand Domain Driven Design is to think POCO. If you can design and build an application using POCO classes, you’re on the right path.

The point of DDD is to make the core code reflect the business domain. When you read the business logic code, there should be very little code that deals with infrastructure concerns. I’ve found .NET developers have a hard time getting to grips with DDD primarily because of their focus on technical implementation. Being prepared to ‘speak business’ is fundamental to getting DDD right.

When staring a new DDD project, I don’t explain all of the jargon up-front because it can be distracting. Instead I’ll focus on modelling entities and relationships, and gently introduce terms like ‘aggregate roots’ and ‘bounded contexts’ when we hit the appropriate areas in the design. This keeps everyone engaged during the modelling process.

If anyone is interesting in a rapid prototyping using DDD, we have a framework that can help. It’s called TrueView, and you can find out about it at

December 10, 2008 12:13
I don't know about other industries, but in finance, where I've spent the bulk of my (gulp) 30-year working life, business knowledge is considered an asset. Well, not for everything - we still have our offshore development teams in Bangalore and New Jersey, places like that, but developers at the more tactical level are at a major disadvantage if they can't communicate with the customers in their own terms. The rewards aren't too shabby either: a developer with a high level of domain knowledge can command a substantially higher salary than a peer with similar technical skills but otherwise deficient.

On getting the customer to describe their actual problem in domain terms, rather than the solution they can conceive of your delivering, I think there's a training period involved. Trust-building might be a better word: it takes time to establish that you can understand a problem stated in those terms and deliver a solution that solves it.
December 10, 2008 20:21
Looks like you let expire. It is currently showing a network solutions page.

Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.