Scott Hanselman's Computer Zen - Hanselminutes Podcast 140 - Rob Conery learns about Domain Driven Design

First time here? Check out the site's "greatest hits" or read a post from the archives. Feel free to leave a comment or ask a question, and consider subscribing to the latest posts via RSS or e-mail. Thanks for visiting!

« Hanselminutes Podcast 139 - Moonlight (S... | Main | South Africa 2008 »

Hanselminutes Podcast 140 - Rob Conery learns about Domain Driven Design

Posted in Podcast | Programming.

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?

Technorati Tags: DDD,OOP,Domain Driven Design,Software,Design

Posted at 2008-12-04 03:10 PM by Scott
Comments [7]
Permalink

Thursday, December 04, 2008 5:15:34 PM (Pacific Standard Time, UTC-08:00)

You can also check out Eric on Software Engineering Radio here</a>.

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

http://gogza.myopenid.com/

Thursday, December 04, 2008 6:02:07 PM (Pacific Standard Time, UTC-08:00)

I love the intro where Rob says he is afraid of becoming the village idiot. Funny stuff : )

http://mdarnall.myopenid.com/

Friday, December 05, 2008 12:35:42 PM (Pacific Standard Time, UTC-08:00)

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.

http://cysemic.com/

Friday, December 05, 2008 1:29:06 PM (Pacific Standard Time, UTC-08:00)

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.

jmcecil

Monday, December 08, 2008 12:09:00 AM (Pacific Standard Time, UTC-08:00)

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 www.evolving-software.co.uk.

Cheers,
Vijay

Vijay Patel

Wednesday, December 10, 2008 12:13:00 AM (Pacific Standard Time, UTC-08:00)

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.

MikeWoodhouse

Wednesday, December 10, 2008 8:21:21 AM (Pacific Standard Time, UTC-08:00)

Looks like you let hanselminutes.com expire. It is currently showing a network solutions page.

Greg H

OpenID
Please login with either your OpenID above, or your details below.
Name
E-mail	(will show your gravatar icon)
Home page

	Remember Me
Comment (Some html is allowed: `a@href@title, b, blockquote@cite, em, i, pre, strike, strong, sub, super, u`) where the @ means "attribute." For example, you can use <a href="" title=""> or <blockquote cite="Scott">.

Live Comment Preview