Hanselminutes Podcast 140 - Rob Conery learns about Domain Driven Design
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: 
- Download: MP3 Full Show #140
- Play in your browser.
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 www.telerik.com.
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.
About Newsletter
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.
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 www.evolving-software.co.uk.
Cheers,
Vijay
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.
Comments are closed.
The idea of Aggregates in DDD is cool. When I read that, I realised how simple the concept was but I'd never fully came to conclusion on my own: I was almost there ...
Its all about the domain.
Love,
Gordon