Martin Fowler and Eric Evans got the ball rolling with Domain-Driven Design a number of years ago. Fowler, with...
his work on enterprise patterns, and Evans, with his work on focusing on the domain and domain logic, were influenced by the movement to discern patterns in programming projects - ones that have proved successful but may not have been consciously understood.
Jimmy Nilsson of the consultancy JNSK AB studied these notions and then began to write a book as he applied these principles in his practice. His book, Applying Domain-Driven Design and Patterns. includes a number of 'guests' who write Domain-Driven Design, Test-Driven Development and associated issues.
Obviously, patterns are no panacea. The best plan in the wrong hands obtains the same or worse results than a bad plan or no plan. Perhaps domain patterns are more effective as an enhancement to software development methods in the hands of experienced developers.
In any case, what Nilsson seeks to do with Applying Domain-Driven Design and Patterns is to describe what he learned as he applied these methods in practice.
His thoughts on Microsoft these days? It seems they are doing more to focus on the advanced developers, he tells us, "they are addressing the need for tooling for domain models." Yet, he notes with bemusement that the company sends confused messages of sorts, as it promotes Entities for ADO, then D-LINQ.
Nilsson said he feels domain design is pretty much de rigueur in Java camps, and that its use can be expanded in the .NET community. We caught up with Nilsson over the summer and present a brief interview here.
Jack Vaughan, TheServerSide.NET: You talk much about Domain-Specific Design. Of course Microsoft has begun to roll out a Domain-Specific Language. What's the connection?
Nilsson: I think it has pretty much in common. There is a complement. The goal of Domain-Specific Language is to focus very much on the domain, and to create a language for the domain. Domain-Driven Design is about that also. There are differences as well. Both kinds of things are observing the same problem and trying to solve it in some similar way.
In Domain-Driven Design, the language focus is very large. Trying to come up with what Eric Evans has coined as the ubiquitous language is the hardest thing -- trying to capture the domain in a crisp language, not necessarily in the language that the domain expert is talking in everyday work. And when you change the language that means you will change your model and your code as well. The DSL should be about a small sub-domain - instead of trying to solve everything with a general language.
Vaughan: A general feeling I got from the book was that you were trying to prove Domain-Driven Design wasn't rocket science. The book is as much about practical problems as about concepts.
Nilsson: The concepts aren't hard. The hard part is understanding the problems. I don't know why. We all the time seem to believe the problems the customers are talking about are simple. In our community, among developers, we have a tendency toward too much of a technical focus, without realizing this problem. Which is a costly thing in the long run.
Eric Evans' book, Domain-Driven Design: Tackling Complexity in the Heart of Software, is a great one. He talks a lot about the concepts. I like a bit more pragmatic information. I had to try it out on my own. I thought someone else could gain from what I learned the hard way.
It isn't rocket science at all. But I think we have had a rough time in the .NET world to use it. The tools haven't been there at all. I think we've had to build it on our own or go for a third party.
Vaughan: There are as of this year some DSL attributes to some of the high-end Microsoft tools. Do you have an impression on where that is at?
Nilsson: I think they are moving in the right direction very rapidly. But the DSL tools they released in the first cycle were more about deployment. Not too interesting for me. But I think they are thinking a lot about this, absolutely. The whole thing about LINQ, for example, is extremely interesting regarding Domain-Driven Design. So is ADO for Entities.
Vaughan: The book does discuss a change in focus from a database focus to a domain model focus. Can you describe your experiences there?
Nilsson: I have been calling myself a database guy in the past. I have been working with databases from the start of my career. It has been a good approach for quite a lot of applications, to have focus on the database, for performance reasons, for example. The database has a tendency of living for a long time, so it is good if it is in decent shape.
But I think also for more and more applications we don't have to focus that much on the database for performance reasons. More applications can run decently without hand-tuning the database part of it.
What I have been wanting to do for a long time was to move my focus a bit away from a technology perspective such as the database to a domain perspective, more on the problem of the domain. .NET as a platform is more suitable for this.
Vaughan: The thing I have seen as I've watched developers as the user requirements are described is that you can see them turning the problem into a schema, one that's like something they've created before. You can see these little bubbles above their heads where they are forming rows and columns.
Nilsson: Yes. That is a good description. I've done it so many times as well. And I probably do that still when I get a little stressed. I don't think it is wrong either. It's good to look at problems from different angles. Another important factor in my case has been test-driven dev, which I think has been a catalyst for me moving from a database focus to a Domain-Driven Design focus.
Vaughan: It seems as though we have to trust the frameworks more, to take on the plumbing, and to free us to concentrate on the application domain.
Nilsson: I think it is very common when you become interested in using an object-oriented programming approach that you start out writing a customer class, and you think how to store it and add methods, and you decide to inherit from a base class for taking care of part of it, and implement a few interfaces. And you let your framework take care of some of the plumbing. I've done that, but sometimes my domain classes became focused on the storage issues, and not that much code was about the domain problem. That didn't make me very happy. Because it didn't buy me anything.
For example, when I talked to my domain experts, I was pretty much distracted. There were loads of things in my code that didn't have anything to do with my domain experts. In a way, a lot of domain experts have become used to talking about tables and rows as well. We don't want that any longer. We want them to help us understand the core of the problem.
Vaughan: Just a basic question here, give us an idea of what you were trying to accomplish with Applying Domain-Driven Design and Patterns.
Nilsson: I wanted to take a mix of the most interesting pieces [on patterns and domains] in my opinion, and combine them and show how they can be applied. To take modern technologies and show how they can be applied. I have seen it so many times - people read a book and the next thing they want is to get more examples, and to see those concepts combined. That was my intention.