DevTeach Day 3 - David Laribee, The Coding Hippie

The model is the code. That's the message David Laribee started off with his Fundamentals of Domain Driven Design. As described by Kyle Baley, David walks us through DDD with the laid back and relaxed view as only he can do it.

"When you say design everybody has a definition which doesn't correspond with yours..."

David posted a quote from Paul Rand, one of my favourite graphic artists (he was responsible for the Art Nouveaux movie posters from the 60s). The quote is completely relevant to DDD since the client has one notion of an Invoice and you have something else. This is the foundation of the ubiquitous language. One of my more favourite Agile tools is the customer, and listening to them is a key action you take with them during the life of building a solution for them.

I really like David's slide approach. Mind you, he's using a MacBook Pro and perhaps his background is Mac-like and more visually focused but he has a nice approach to presentation. All of the slides are simple in nature and really focus on the message. This is very much the Lawrence Lessig approach to presentation where you don't need a lot of fluff and flashy lights. For example a picture from the movie 300 with a the simple caption of "Impossible Odds". Brilliant!

Its tough trying to find the domain experts, the subject matter experts, on a project. However you have to work with them. It's more of an art than a science to try to extrapolate the information that you need to build systems out of your customers or experts. Of course having 7 experts in the room you'll probably get 10 different answers as to what an Invoice is. Or an Employee. Or a Product.

David walks through the basic patterns used in DDD (Entities, Value Objects, Aggregates, Repositories, Services).

A couple of tips for Repositories. 1 Repository for each Aggregate Root. David (and this is my preference too) is to have a Customer Entity and a CustomerRepository Repository. There's a big debate out there about calling Repositories Repositories and you can stand on either side. Sometimes a Repository makes more sense to call it using a domain concept rather than a pattern name. For example a FileRepository might be called a Folder. I would call it Folder in the domain rather than a FileRepository.

All in a great presentation, however we just got a fire alarm which has basically put an end to the session. Well, off into the cold now with the rest of the geeks.