Domain-Driven Design By Eric Evans

I must say, emphatically, that Domain-Driven Design by Eric Evans should be a required read by any software engineer in the field that is using an object-oriented language (I can’t speak outside of that yet).

"This book belongs on the shelf of every thoughtful software developer."

–Kent Beck

This book has been out for awhile – I first read  Applying Domain-Driven Design and Patterns: With Examples in C# and .NET by Jimmy Nilsson – and although it was a good starter book, in retrospect, it would have been better for me to start from the source.

To me there is a ladder of growth emerging:

1. First the goal of writing code that follows good object oriented design.  ie. loosely coupled, encapsulation, programming w/interfaces, etc…

2. Then we see patterns emerge in that code base – ‘factory pattern, strategy pattern, inversion of control’ – not even as much as ‘in code’ but as a way to ‘talk about code’.  When one dev says to another ‘we need to use a factory here’ – it’s a common language.

3. Once these start to emerge, there is an architectural awareness – a ‘how do I fit these pieces together’.  DDD by Eric Evans (and Patterns of Enterprise Application Architecture by Martin Fowler) is the next great place to explore.

What is interesting is several projects I’ve seen were driven from a technology perspective and not from a domain driven one – and have required someone coming in and ‘saving’ the project.

In my current project it’s been an evolving model, expanding and refactoring as I have learned more of the business and it’s rules.  Our jobs as developers are twofold – be experts in the technologies we work in , but more than that – to learn how businesses work – to relate to customers, etc… it’s quite a task!  Many times I see organizations attempt to conquer the problem through the technology only without really grasping the domain being modeled.  

I started with the layered approach, and honestly began to learn how to shape the parts as the knowledge of the domain began to shape and form.  Evolving is the keyword, to me though – it’s a learning process, there are times that difficult decisions are made when shaping the code, and yet when trying to stick close to first being conscious and aware of ‘how’ I’m writing the code.  Having a DDD up front, separating the domain, repositories, understanding ‘specification’, ‘factories’, etc… all produce an environment where the software can shape and grow without becoming too unwieldy.   Eric Evans helps to shape and form his experience is a way that provides insight and wisdom into domain-driven development.

(see also )


One thought on “Domain-Driven Design By Eric Evans

  1. I recently had the opportunity to meet Eric Evans at here in London. I fully recommend attending such an event.

    In the right project following DDD principals benefits the developer, with some helpful guidance and patterns, but most importantly really pushes business value first because you really have to understand, what business problem you’re trying to solve, as opposed to a technical challenge.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s