D'Arcy from Winnipeg
Solution Architecture, Business & Entrepreneurship, Microsoft, and Adoption

Dev Teach Day 4 - David Laribee: Fundamental Domain Driven Design

Thursday, November 29, 2007 10:54 AM

Today was my crash day. I slept until noon today, not from an alcohol induced stupor but just from a crazy fire-hose-drinking, shindig-happening, information overloading weekend (which *may* have included alcohol at various points).

*Need to read Eric Evans book on DDD*

Domain models is a pattern for construction of a system.

Take the specific areas of an application that have high complexity and focus there.

*David has just won the most metrosexual presentation award at Dev Teach for his slide deck.*

Model == Code
You don't need UML to create a model, or other "modelling" languages.
DDD says that the code is enough of a mapping for a model.

Models are Forever
Maintenance starts on Day 1, and are the systems we're building able to last "forever"?

Data is a happy side-effect

Ubiquitous Language

Be focus on the understanding of what the domain is.
Define the problem and work on it in isolation from.

Postmodern Programming

James Noble/Robert Biddle
"Individuals interacting with other individuals"
(David is talking about artists...this guy is like the US version of Justice Gray!)

Impossible Odds
Throwing a requrements doc over the wall and saying "get it done"

The Fountain Head (or, That Architect You Used To Work With...)
Architect who's 'bat shit crazy'...that's a great quote...I might combine that with my other new favorite quote: Only developers who are bat shit crazy think data is more than a happy side effect (David, I'll let you use that if you want).

*I need to see Tetsuo X*

Seperate your model from your infrastructure

Your domain model needs to stand alone from any of the other layers that you have in your architecture.

DDD - The pattern Language

- Real world thing...a noun...an identity
- The celebrity of the domain model

*Scott Belware is in the house*

Value Objects
- Side effect free functions (they are immutable)
- Methods return value, but don't alter their own state


- In memory collection
- Place to get your entities
- RUD: read, update, delete

- The most overloaded term in software development

*demo time...seriously...I want a Mac Powerbook now...*
*David uses a whacked out color scheme for his dev environment...black background, orange text...*
*It is crazy hot in this room...the fact I'm wearing a sweater and I have a small piece of the Sun sitting on my lap doesn't help either. OMG, the fire alarm just went off and I'm not even kidding.*

*And we're back*

Domain services are laser focussed (until they don't need to be)

Application services translates things into DTO's which transfer back to the UI layer (one example...Jeremy mentioned an idea of a 'membrane' in one of his presentations, guessing the one on design patterns for winform dev).

Domain service executes some action within the domain (i.e. FundsTransferService)

?So how do you model something along the lines of a transaction fee, where the fee can be determined via values in the database if "the data is just a side effect"?

Most services end up looking like transaction scripts.

Anemic Model Anti-Pattern
What happens when the domain is not a model of the ubiqutous language (your domain objects are basically gets/sets or DTOs)

?Q. So you would create objects based on a certain status (AccountIsInactiveInLast60DaysSpec) instead of making a generic object that would hold a value from the database or a config value

A. If you capture an item such as AccountIsInactiveInLast60DaysSpec, then add it to the domain...use it...but remember that you should always be evolving your model...refactoring it, tweaking it, etc. It might be that you decide you don't need it as a class within the domain to identify that aspect of the domain, but it might be that you do (that wasn't Laribee's response, but a colleague sitting next to me)?

Domain model is not a data layer.

AMAZING presentation...man...now its time for Justice Gray :D



No comments posted yet.

Post a comment