Blog RSS Feed

DDD Sydney 2011: Guerilla Domain Driven Design

Thu, 21 Jul 2011 00:03:00 GMT

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.

Domain Driven Design - DDDSydney 2011

View more presentations from thinkddd

DDD Sydney 2011 : Git, YouTrack and TeamCity

Wed, 20 Jul 2011 23:59:00 GMT

From my presentation at DDD Sydney 2011 – the slides from my talk covering Git, YouTrack and TeamCity

Git, YouTrack and TeamCity - DDDSydney 2011

View more presentations from thinkddd

What is Domain Driven Design?

Tue, 17 May 2011 23:12:00 GMT

“… the key to expert performance in many fields is domain knowledge rather than intelligence.” Don Reinertsen

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.

In a waterfall approach this leads to large requirements documents that are diligently collated, analysed, reviewed and approved. These documents are then given to development teams to turn into working software.

Agile approaches can also accept the requirements documents that waterfall tends to produce, but for them to actually progress forwards they must be broken to small tasks and stories which can then be queued ready for development.

Domain Driven Design to a large degree steps back from these two distinct ends of the spectrum, and looks at how the requirements are gathered in the first place – if you like, it bridges the gap between doing everything up front and everything at the last minute.

DDD understands that requirements are never ‘done’, but exist as a living document. More importantly, the living document in question is actually the software itself – all other documents are an artefact and reflection of the code.

As the software system develops and grows, deeper understanding of the problem grows too – DDD is all about the discovery of the solution through deeper understanding of the problem.

Where DDD really differs though is that it sees the software system as a reflection of the business process, an enabler rather than the driver. DDD is deeply concerned about the business processes, business terminology and practices. Technical concerns are largely secondary and a means to an end.

The Ubiquitous Language is at the centre of DDD – this is a shared and growing language. A negotiated language derived from the business terminology and enriched by the development teams. If a business person doesn’t understand a term in the UL, then the chances are the UL needs an evolution. If a technical person doesn’t understand a term in the UL then the chances are they need a conversation with a Domain Expert.

The Domain Experts are the second essential component of DDD – people who deeply understand the business domain, and the business itself. These people are integral to the development process. They may not be required “full time” like the traditional Product Owners of some Agile methodologies, but they must be accessible continually, and be prepared to invest time in the process. Domain Experts are not to be considered outsiders, but as the core of the DDD process – they are as much a part of the development team as any developer or tester.

DDD doesn’t begin and end – it is a constant process of re-evaluation, refactoring, remodelling and redesign – every conversation should bring you to a closer understanding of the problem. At no point is DDD ‘done’ – it is always there; the Ubiquitous Language grows and develops, the Domain Models change as understanding changes, code is restructured and refactored to better represent that understanding.

Artefacts will come and go, but only one really matters – the code base. It is the only expression of the solution that is free of abstraction. While documents may try to explain or describe the system, only the code does so without losing information. This means that in DDD the code must remain of high quality, be clear and expressive, be free of technical abbreviations or jargon, and as far as possible should make at least some sense to a Domain Expert when explained to them.

Clever code doesn’t work in DDD, nor do magical processes or “you don’t need to know” components. Domain Experts shouldn’t need to become developers to understand what the key parts of the software system is doing for them. They also shouldn’t need to think in terms of databases or batch jobs or other technical concerns.

DDD is the ultimate expression of Agile – it is about dealing with a constantly shifting and evolving set of requirements – because as anyone who has ever been involved with a software project knows – it is very rare for a requirement to remain intact from the beginning to the end of a project, and almost impossible for it to do so as the business grows and changes.

Through constant conversations, DDD will guide you to an ever more accurate software representation of your business process.

My Objective Today is to Make You Think

Mon, 19 Jul 2010 00:03:00 GMT

“Maybe There is a Better Way”

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’

(slides here)

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.

Obviously some of this has roots in DDD, the Ubiquitous Language is obviously an attempt to traverse this chasm that seems to exist between us.

Then I touched on user interfaces, and how they are so rarely designed the way people think – normal people think about their objectives and goals, not in terms of data like we developers do. Inductive UIs are focused on tasks, unlike the traditional data driven UIs that we tend to throw at users – users and people don’t think in grids and columns and rows, they think “I want to change my address”, not “open my customer record, edit the three fields under address and save to the database” – only a sadist or a developer would think that way.

And finally I touched on things like NoSQL databases, which neatly solve a communication problem – they stop us thinking about How to store information and let us focus on What we are storing and Why.

And lastly I tried to show the link between CQRS and these business problems – how it made you focus on the language, on tasks and objectives and how it let you detach the How from the What and Why.

But most importantly, what I was trying to do in that presentation was to throw some non-mainstream ideas out into the audience, to spark discussion and debate, and to get people to think – Maybe There is a Better Way

If only a few of those in the audience went away and Googled some of the ideas I was talking about, it will be another step towards moving development away from it’s heavy focus on technology and technological solutions – and towards a people and business driven focus, where technology is an artifact, not the deciding factor.

DDDSydney Presentation : Stuff About CQRS

Sat, 17 Jul 2010 22:52:00 GMT

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.

I’m not sure how much sense the slides make without the talk, but like always, drop a question in the comments if you have one…

Stuff About CQRS

View more presentations from thinkddd.

Sydney Architecture User Group Presentation Slides

Thu, 27 May 2010 04:53:00 GMT

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.

Practical Domain Driven Design, CQRS and Messaging Architectures

View more presentations from thinkddd.

Sydney Architecture User Group Presentation

Mon, 10 May 2010 23:16:00 GMT

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.

JetBrains have also given me a couple of licences for ReSharper and dotTrace to give away to any interested .Net developers, so if we get enough people, best questions of the night win them.

Hope to see you there.

Title: Practical Domain Driven Design, Message Based Architectures and CQRS

Presenter: Jak Charlton

Date/Time: Thursday 27/05/2010 06:00 PM

Where: Grace Hotel, Kiralee or Pinaroo Function Room, 77 York St, Sydney, NSW 2000

Abstract

The original book on Domain Driven Design was subtitled “Tackling Complexity in the Heart of Software”, and even where a system does not merit “full on” DDD, many of the practices and principles can massively reduce the complexity of software, especially when combined with messaging and events.

Presenter Bio

Jak Charlton, is now based in Sydney, Australia, and working as a Senior Consultant for Readify. Jak is a well known community figure in the Microsoft and .NET worlds with a reputation for a passionate view of development. With primary interests around Domain Driven Design, software architecture, and putting the world to rights one debate at a time, he is a strong believer in principles and practices, allowing developers to concentrate on delivering business value.

What Eric Evans Learned Since the Book

Wed, 28 Apr 2010 23:23:00 GMT

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.

This speech can be found in two different versions:

Sydney Alt.Net Presentation

Tue, 27 Apr 2010 05:16:00 GMT

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

Download: A Practical Guide to Domain Driven Design: Presentation Slides

Some questions came up that could really use follow up posts, so I hope to get some answers up shortly to those. Thanks all for coming, for listening, and for asking some awkward but useful questions.

A Practical Guide to Domain Driven Design: Presentation Slides

We are not doing DDD

Wed, 08 Apr 2009 19:36:00 GMT

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.

I’m certainly not known for my subtlety, nor for my coding skills which are by no means the best you can buy in. What I feel is my key strength is my ability to look at the wider picture than sometimes teams have the luxury to do, and to push some of my enthusiasm and energy into a project. I’m sure I’ll blog in the near future about the actual impact my presence has had on the team and the project, but this blog is primarily about why we are not going to be doing DDD.

But Jak Does Domain-Driven Design

One of the factors that made the client hire me was my knowledge around DDD, or at least my projection of that knowledge on the web. It was certainly something they felt could have helped some of their past and ongoing projects, and something they thought would be a real help to them. I don’t think anyone suspected I would come in and say “Hey guys, lets all do full on DDD”, so luckily for them I didn’t, what may have surprised them is that I did pretty much the opposite. In fact my early assessment was this project really didn’t have any need for most of the stuff in DDD – fundamentally it, like the other projects in progress by the same team, was a CRUD application at heart. Data out of the DB, a bit of manipulation, some input by users and services, and dump the data back to the DB.

Many out there disagree with my general statement that CRUD applications don’t make good candidates for DDD – but not only do I stand by that statement, but two of the other client’s projects nearing completion showed some of the real pitfalls of DDD. While previous projects had attempted to use parts of DDD to help simplify their applications, it had not all gone according to plan.

What Goes Wrong With DDD Over CRUD – The DB Domain Model

The first most obvious weakness of the systems that existed was the Domain Model. It had started with all the best intentions – there was a legacy database that acted as the primary store for the business, and many different systems used and updated this database. So NHibernate was chosen as a way to create a Domain Model over the database, to abstract the system away from the DB and to treat it as a legacy system.

Unfortunately one of the primary requisites of DDD is direct involvement and commitment from the business to the project and in this case that wasn’t part of the project. The team had to come up with their own Domain Model – and in doing so had fallen into the classic pitfall of creating a “domain model” that mirrored the legacy database. Now not only was there a legacy database, but essentially there was a legacy domain model too. A large amount of work was put into getting this NHibernate model right, and in hindsight it has probably consumed disproportionate resources to get this model overlaying the DB.

In addition, although at present it simplifies many operations against the DB, it does not abstract the code base from the database, it just acts as a heavyweight data access layer. Worse still, many of the “hacks” that had to be made to get NHibernate to work with the (frankly terrible) underlying database structure, had actually made the system very fragile, and fairly rigid.

Lesson to be learned: Do not drive your domain model from the database, drive it from the Domain Experts, user stories and use cases. Without significant commitment from your business to provide you with those experts, you are at risk of creating a significant amount of code, with no quantifiable benefit.

What Goes Wrong With DDD – Where is The Ubiquitous Language?

A somewhat related problem that is now obvious, again in hindsight, is that there was no clear attempt made to extract any kind of Ubiquitous Language out of the (non-existent) domain experts, nor from the business analysts. The language between the teams has fallen into the classic pitfall of a language confused across development teams, technical support teams, legacy systems, and business terminology that was not clearly defined nor understood.

Lesson to be learned: Get your language sorted out early on. Insist upon a basic glossary of terms at the very minimum, regardless of whether you do DDD or not. This will save countless hours of mistakes and confusion, and will get new developers and business people up to speed on the project in record time.

What Goes Wrong With DDD – Services Services Services!

I sat down early on with numerous team members and the architect who was in the unenviable position of making all this stuff work, and ensuring all the new stuff learned from previous mistakes and moved forward.

One of the things that became apparent to me was that while discussing architectures, the term “Services” was in frequent use, more than frequent to be honest, it permeated through everything. It was a term that business analysts and project managers were comfortable with, and perhaps that was the reason that “Services” was the terminology for decoupling things. From that it soon became obvious that Services of all kinds had become intrinsic to the current codebase, from Web Services, to Application Services, to Domain Services, and on and on.

Now, there is nothing wrong with “Services” per se, but interestingly when I suggested a new architecture for the new project, and discussed this with various people, I managed to explain the entire new architecture with almost no use of the word “Services”.

When I pointed this out, it soon became clear we could discuss a decoupled system, with little direct reference to “Services”, as fundamentally Services are an implementation detail, and have little important to the overall architecture of a system. Now instead of talking about Service being called, we can discuss messages being moved around the system, without any need to worry about what consumes them, or how they are delivered. The final architecture includes services for sure, but they are the implementation of a much more abstract concept.

Lesson learned: Technical language can become the norm, and then it tends to be the solution to every problem. Step back from things once in a while, and see if the terminology you are using is driving your architecture and design. Try to avoid using implementation terminology in relation to things like architecture, or it will drive the design.

So Where Are We Now?

The one really big thing that has happened over the past two weeks is that the introduction of some new blood to the team, along with some new ideas, has really revitalised the team. Everyone has new found energy. We also have a broad consensus of what didn’t go right on the last two projects, and the things that went well – we now have a strong idea of how to build on the strengths of the existing systems, and where we need to compensate for the things that didn’t turn out as planned.

Luckily the teams involved are all really eager to learn, and really keen to make each and every system better – and that alone will make a huge impact to how successful this project will be.

Well, this post has turned into a bit of an EPIC … and is far too long to continue without boring everyone to death … so I will post the concluding part soon. And with luck I may explain my opening statement … “We Are NOT Doing DDD”.