DDD Sydney 2011: Guerilla Domain Driven Design
In my talk for 2011 I wanted to cover the fundamental messages that Domain Driven Design is based upon, rather than the practices and software patterns that all too often become the focus
Many of the slide quotes can be found in the Domain-Driven Design book by Eric Evans – so if they don’t make sense, ask a question in the comments, or read the book.
DDD Sydney 2011 : Git, YouTrack and TeamCity
From my presentation at DDD Sydney 2011 – the slides from my talk covering Git, YouTrack and TeamCity
What is Domain Driven Design?
Domain Driven Design is a software development methodology, intended to achieve a software system closely modelled on and aligned with real business processes. Traditionally development tends to be a technically led process, where requirements are passed from the business to the development teams, and then the development teams go off and produce their best guesstimate at what the requirements said.My Objective Today is to Make You Think
I recently presented at DeveloperDeveloperDeveloper in Sydney, and although my talk was Stuff About CQRS, I opened with the slide
My Object Today Is To Make You Think … ‘Maybe There is a Better Way’
The real focus of this was around how normal people think, and how unlike normal people we developers really are. My role in development is all about enabling better communication, because fundamentally I believe the real value a developer brings to a project is not technical, but is in the way they interact with the team, and more importantly with the normal people they are actually creating software for.
DDDSydney Presentation : Stuff About CQRS
I was pleased to be able to present at Developer Developer Developer Sydney yesterday on the topic of CQRS …
To make this a little less bland I covered some of the aspects that make CQRS a good architectural fit from the perspective of users, as a task focused paradigm within your system.
Sydney Architecture User Group Presentation Slides
At the invite of Omar Besiso (@omarbesiso) and Paul Glavich (@glav), I am presenting an extended version of the presentation I gave on DDD, CQRS and Messaging Architectures.
There are two extra slides in the middle, covering Domain Events specifically (I covered them in the talk last time, but didn’t really have a slide), and half a dozen slides at the end extending the part about CQRS, discussing the theory and the practical benefits.
Sydney Architecture User Group Presentation
Feedback on my recent presentation on Domain Driven Design at the alt.net user group was good, and I have been asked to repeat the talk at the Sydney Architecture User Group on the 27th May 2010.
The content will be fairly similar, but with a few extensions based on some of the questions posed at alt.net, and with an expansion of the CQRS section.
Slides will follow soon after the talk, and we are keeping fingers crossed that we may be able to record this session, though hosting the resulting file could be a challenge.
Hope to see you there.
What Eric Evans Learned Since the Book
At the recent Sydney alt.net presentation I gave, one of the questions was “has Eric Evans written a book about what he leaned since the book” (or something to that effect). Well, he hasn’t yet done a second edition, but he has given talks a number of times on just this subject.
Sydney Alt.Net Presentation
Tonight I presented on Domain Driven Design to the Alt.Net group in Sydney at the invite of Richard Banks.
As a follow up, attached are the slides I used, feel free to distribute and use on the Creative Commons Licence
We are not doing DDD
Recently I joined a new project, and within reason, and excluding some legacy systems we have to talk to, we have the “luxury” of an almost greenfield project. Probably as greenfield as you realistically get anyway.
I was brought in partially as a good old fashioned coder (the project needed another person cutting code) and partly as guys in the team knew my blog and general approach to software development and wanted to inject some of those ideas into the team. I’m not sure exactly what they were expecting, and I’m not sure if they got what they were expecting, but suffice to say the first two weeks has been turbulent and frenzied.
Invariants or Contextual Validation?
Greg Young made a good point to me regarding my last post about Validation, Consistency and Immutability , specifically around validation – even more specifically he thought I may have simplified it too far. I was trying to cover the basics of the subject…
Sample Application First Steps
As mentioned in my last post, the DDD Parcel Service is opening up for business soon. Also as mentioned, the first thing I did was to grab my Domain Expert and start some initial conversations around the first areas I am approaching – the Booking service.
I’m going to get boring again, but the documentation is far more important in DDD than many of us Agilists would traditionally like – at least the resulting artifacts are, so it is important to me to show in the documentation why I am making code decisions.
The Beginning of a Sample Application
The Domain Driven Design Parcel Service is a small competitor in a hugely competitive market. With such competitors as UPS, FedEx and DHL, we are at a competitive disadvantage, and need a solution to cover our interactions with our customers, and to streamline our internal processes. This software will be at the heart of our expansion plans and needs to grow as the business does. Although we are currently only a national carrier in the UK, our long term vision has much wider reach.
Validity, Consistency and Immutability
In this series I first mentioned these things back when I introduced Entities and Value Objects, I said that you should try and ensure Entities are valid at all times, and that Value Objects should be immutable. The discussion around Aggregates and Aggregate Roots has also proved to be of some confusion, the definition from Eric Evans of an Aggregate says “A set of consistency rules applies within the Aggregate’s boundaries”.
The Specification Pattern
A Specification is, in simple terms, a small piece of logic that sits on it’s own and gives an answer to a simple question … “does this match?”
With a Specification we split the logic of how a selection is made, away from the thing we are selecting.
Living In The Enterprise
Domain Driven Design appears to be at odds with large scale distributed systems, it is after all methodology to design and write application software, and in SOA we don’t have applications – we have services (this is one of those times I don’t mean Domain Service)
The foundation of SOA is an environment of distributed systems talking via messages, sent between services, probably over message busses – not applications like DDD
What Kind of Applications is DDD Suited To
In many conversations, and in many comments here, you hear phrases like “well that’s not really suited to DDD” or “DDD isn’t the best fit for that problem”. You even see those kind of comments on my blog, and often they are posted by me.
This obviously leaves a number of people confused, after all DDD is the wonder cure for every software illness, surely there is nothing it cannot do!!!!
Where is Domain Driven Design a Good Fit?
The Repository Pattern
I seem to have taken a fairly long time to get here, and it has been mentioned in passing, but now we get to the last major part of the Domain Driven Design picture – Repository.
In traditional architectures, your application talks to some kind of database layer, and asks it to save or retrieve your objects. DDD is slightly different, after all, remember I said “There is no database”
Domain Services
There can be no word more common in development, and no word used for such a multitude of different things as “service”
It was therefore unfortunate that Eric Evans introduced yet another concept of Service in DDD, one which has since been referred to by some as a Domain Service. However, people often use the term Service in isolation, as Eric did in his book – so if it is in relation to the Domain, it is probably what I prefer to call a Domain Service – otherwise it is likely to be one of those “other” services.
Aggregates and Aggregate Roots
Some things belong together, like Apple Pie and Ice Cream, or Sonny and Cher. And so it is with Entities and Value Objects (VOs) – some of them belong together.
Aggregates are groups of things that belong together. An Aggregate Root is the thing that holds them all together.
Entities and Value Objects
Back in the good old days we used to have things called business objects, these were classes that held some data, had some methods, and we threw into a database.
DDD has refined this concept a little, by splitting the idea of these business objects into two distinct types, Entities and Value Objects.
Command Query Separation as an Architectural Concept (CQRS)
The concept of applying CQS at an architectural level says, our Domain and transactional operations will use the Repositories, but for Reporting operations, we will use a separate mechanism. The Command is the Domain operations, the Query is the Reporting operations.
(update 2010: CQS as an architectural concept has now been coined as CQRS Command Query Responsibility Separation)
There Is No Database
If you think about this apparently stupid statement, in the context of Domain Driven Design, it has a subtle and important point - DDD is all about the domain, not about the database, and Persistence Ignorance is a very important aspect of DDD.Bounded Contexts
Bounded Contexts in DDD is one of the “advanced” topics, it doesn’t even appear in the book until well over halfway. Suffice to say you could model your entire domain as a single thing, with a language to cover everything, but if you look at the business you are trying to model, it is unlikely that is how they see things.The Ubiquitous Language
The concept is simple, that developers and the business should share a common language, that both understand to mean the same things, and more importantly, that is set in business terminology, not technical terminology.
Developers have historically had a hard time with talking to the business – developers are by nature technical, and have a bad habit of letting their technical “geek” terms leak into their conversations. We are all guilty of it at the best of times.
Domain Driven Design: A Step by Step Guide
There is a lot of interest in DDD recently, both in the book, and in the methodology, and in the buzzword.
As a book and methodology, DDD is an excellent way to approach complex software problems, and make them far more understandable and manageable. As a buzzword, DDD is in danger of being corrupted like many other good software practices.