Bio Eric Evans is a specialist in domain modeling and design in large business systems. Since the early 1990s, he has worked on many projects developing large business systems with objects and has shared his experience in the book "Domain-Driven Design," Addison-Wesley 2003. Eric now leads Domain Language, Inc.
Software is changing the world; QCon aims to empower software development by facilitating the spread of knowledge and innovation in the enterprise software development community; to achieve this, QCon is organized as a practitioner-driven conference designed for people influencing innovation in their teams: team leads, architects, project managers, engineering directors.
Floyd’s full question: I’m Floyd Marinescu. I’m here at QCon New York with Eric Evans, creator of Domain-Driven Design. So Eric, it’s been eight years since your book came out, if you would update it now, 2012, based on where technology has gone, what would be different?
Eric: So, I think the fundamentals would not be that much different because the fundamentals by their nature don’t change very much, but of course some of the technical explanations would be different. The book makes the assumption which was valid in the mid, you know, 2004 time frame that most people would be applying this using object-oriented programming, so all the examples are in Java, all the modeling assumes pretty much object modeling. And now, I think that is certainly one thing that would be different. But most of the fundamentals I would stick with, yes.
Right. Well, I think that NoSQL is a very good thing for DDD, actually, a breath of fresh air. For the last fifteen years or so, we’ve been trapped in the O/R mapper, the object-relational mapping, and I’m a huge fan of object-oriented design and object-oriented programming and I think as we assimilate functional and other ways of programming which are all good, I think objects will remain an important part of the mix. But the objects have been crippled for a long time by being tied to heavy frameworks like J2EE, but also and maybe more insidiously to the necessity of mapping to relational databases.
And the sad thing is that relational databases are one of the great inventions and relational modeling is actually a really powerful way to look at some problems. Object-oriented is a powerful way to look at some problems, but you tie the two together, the way we have, and you just take the guts out of both of them. So I think it’s a relief, actually.
Right. So, I think that is one of the first things people probably do with NoSQL is to use it to store object data. So, if you try to store the data of a rich kind of finely structured domain object, in a relational database, you get into all kinds of challenges which people are probably all too familiar with. And so, what tends to happen is that you make compromises on the modeling of the objects and make them less finely composable. But, say MongoDB is probably the most popular of the NoSQL databases right now. It’s key-values and it’s composable, so the structure of it actually maps to the structure of an object much better than a relational database does. You can take a fine grained object and you can transform it into the dictionary of dictionaries kind of structure.
And so that kind of map, that kind of document database they called it, but it’s really a storage of maps, that works very nicely. You could also use a graph database that way because again it’s an object, it is a graph. Of course, you’re not storing the behavior, but then you bring it back and you turn it back into objects, that’s what we always do with when we’re mapping anyway. And I think that will be one of the first steps that people who have come from the DDD world will start by just using it as a data store, but it will be a better one than the relational because the impedance mismatch is a lot less, I think. And of course, the end memory database is, that could be even, even more natural.
But then, another thing that will happen I believe and I hope is that people will start using the capabilities of these things. So I mentioned graph databases, well, yes, a graph database could be used to store object data. But the real exciting thing about a graph database would be to use its graphicness to actually start to model your domain in ways that allow you to post queries, really insightful queries in terms of graph structures. And, so I think that as these things mature, there’s always stages of maturity and use of a new tool and so I think we’ll become increasingly using the capabilities that are inherent in that tool.
And people are overly interested about some of the DDD patterns like say entities value objects and events, domain events, these things have a certain manifestation in the object-oriented world, but the core of Domain-Driven Design is the Ubiquitous Languages, having this very clear conceptual model of the domain that can address some important problems. And, as I even said in the book eight years ago, because objects were at that time and still are the dominant paradigm, you would choose a model that works well with objects and here is how you would do that. But if you have another powerful modeling paradigm, say graphs, then devise a model that works well with that paradigm. You’re looking for a system of abstractions that helps you solve important problems within that domain. And some mixture of the paradigms that we have now I think will really put us in a good place.
Hopefully, we won’t do again what we did with relational which is to make it a kind of bad match to OO, you know, marry the two together and in a way that, I mean maybe, who knows, maybe after a few years of NoSQL, people will rediscover SQL and the things that SQL is really good at which I think would be a good thing too when you really want to start manipulating sets. I mean if you think about it as an abstraction for set manipulation, then SQL and relational databases are wonderful thing. We just almost forgotten that because we’ve just used them as a bad way to store objects for fifteen years.
Floyd’s full question: So do you see a need to create new patterns to map to some of these new concepts like for example in graphs you can add attributes to relationships? You know how would you map that into the current DDD lexicon or do you need new patterns for these new paradigms that weren’t in context when you thought about DDD in the first place?
Eric: I think that that is entirely likely that the building block patterns which was one of the parts of DDD would first be rethought a little bit and there might be slightly different ones in different paradigms. I mean you gave a great example, if you can put attributes on relationships, then what do you do with that? That’s sounds like a wonderful capability something that most of the objects languages don’t have. So if you do that, what is an association? Do you need a building block pattern or building block patterns to describe them and I guess we’ll see, you know, I would say that experience needs to be the driver here.
But, what I would hope people would take away would be that the fundamentals are still much the same. If we want to look at that domain and talk to the domain experts and get a deep understanding of what the problem is, what the concepts of that domain are in structure that into a model that we can actually render in code. And to do that, we need be thinking about the paradigm we’re working in, as in if we’re working in a graph database then we need to be thinking about how can we represent this domain as a set of graphs. If we’re working in objects, we need to think about how it breaks down into objects. And then after a few years of really working with these tools, the patterns will emerge and people will find good ways to do it, I believe.
Yes, well, again, I think that what you need in order to do DDD is a powerful abstraction tool, something that allows you to take that ubiquitous language and render it in code. So, in functional, we certainly have the abstraction power and a lot of people in functional programming tend to think in terms of basically creating their own internal DSLs, that is Domain Specific Languages. So that’s one style of programming which people in functional tend to use and say, well, build up a language basically that you can use to describe your domain. So that’s probably one of the areas I expect we’ll work out. We’ll end up with more DSL-like style.
And I think this kind of internal DSLs was one of the popular styles within the OO world although it never spread so widely, but it was influential.
I think another is that when you start looking at problem, for example, I’ve been looking at functional programming for the last few years and I’ve done a little bit of work in Clojure, for example and partly because I really feel, I mean, you know, I want to, I get excited about new stuff too, and so I wanted to get my hands on, you know, something functional. I chose Clojure because it’s a really pure functional language and you can’t cop out and do it the OO way in Clojure, so it forces you to really think about it as a functional problem.
And one thing I noticed, and in retrospect this doesn’t seem surprising to me at all, is that the nature of the models and the way that I approach the problems starts to change. And, one of the things I noticed is that I’m much more likely to view things as sort of streams and sequences. So you look at your domain and you start looking for the things where you’ve got a stream of things happening or stream of things you can process. Because functional language is sort of structured that way and you’ve got a function and you fit it as stream and out comes another stream of something.
I guess my point is, that is has the abstraction power that we need. There is, if you take the mentality of how can I express the ubiquitous language here and what shape should my model take? If you’re really open-minded about those things you’ll find ways of creating nice DDD solutions with functional and then we’ll need to do patterns and variations of the old patterns. Some of them are natural like value objects which was always one of the things I used to preach about a lot. But, in OO you have to kind of say, you know, make an object like this. In functional you almost start there. That’s the default way that a data structure, at least, would be. It is not an object and you still have to say, “Well these functions and this data structure together accomplish this thing.” And in Clojure, the concept of a protocol is pretty clear. So anyway, value objects map over pretty easily, very naturally.
Then entity, what is an entity? The identity part of an entity is still relevant, but some of the other aspects of it may just not apply. Domain events? I think that’s going to be one of the real keys to making DDD work in functional is to think more in terms basically of event sourcing which was one of the, you know, has been one of the big trends in DDD for the last several years. And now, when I start looking at problems in the functional world I say, “Ah, event sourcing actually fits pretty well.” A sequence of events again, that stream, being processed to create basically a current view of an entity. So the entity isn’t there as such, it’s not stored state, but if you want to know what a particular entity looks like at a particular point of time, you take the stream of events you put it together, I mean that’s event sourcing. Works pretty well with functional, actually. So we’re just at the beginning of this, you know, that’s the exciting thing, it’s fun. I mean, well, we’re not really at the beginning I’m sure because functional is an old, old style of programming, but we’re at the beginning of maybe of widespread adoption.
Eric: Well, I think in this stage it’s almost completely neutral. The business logic has to happen somewhere and when I first started out, we were in the client-server period of time by which we meant a thick client and I guess you could call it a thin server. So the thick client was written in my case in SmallTalk, and that’s where most of the business logic happen and you mostly talk to the server when you want a data. So you do queries over the network and get back a chunk of data and then you do all your logic locally.
I saw that keynote, that was Cameron Purdy, right? And I think part of his point was that it could sort of happen either place and that there might be quite a bit of fluidity there and you might be disconnected and do things locally and then be reconnected. But I think from the point of view of DDD, the thing is you have to say where are we dealing with our domain logic, the complexity of the problem and can we isolate that from all the technical concerns. So if you’re in a browser, the way browsers have been in the past, then that would be a bad story because those are very, you know, there’s very little abstraction power and very little way of isolating logic from anything else.
And, last, people carry over that mentality, the old mentality of the browser. They have to let that go and really think about it differently. And, of course, not the same way they think about the server now either because on the server you’re thinking of something which probably has tremendous resources compared to what you might have on a mobile device, so you might have to keep it more lean. But, also, as maybe it’s more stateless because if you’re there on the device, you can say, “Well, I know who I am and who my user is and I’m not trying to statelessly serve in clients. I’m focused on what my user is doing right now.” So, it could perhaps end up being more stateful. We’ll see here, I just think we just don’t know where it will go.
Floyd’s full question: With JSON, we’re starting to see more architectures where you have JSON as the sort of the data contract between very loosely coupled systems and how does that emerging architecture or pattern maps to DDD concepts?
Eric: I think that in a few ways perhaps, but maybe the most important thing is the concept of the bounded context because one of the things about when you say loosely coupled then you know you’re exchanging JSON and so people start to view the JSON as sort of neutral as if this data I can just take it from point A to point B and use it wherever. And this is I think an important conceptual error or just a gap. The data structured according to some conceptual model that those labels mean something, I mean they are words that mean something in some language in some context.
And the structure of that data, so if I find here that is says, you know, “address” and then some stream. What does that mean? It could be a street address, it could be, you know, a meaning for a different kind of system. It could be the memory location in some system. I mean the word “address” doesn’t actually mean anything unless you have context around it. So this JSON schemaless data packet, I think you will ideally have a consciously cultivated bounded context that says, “These are the concepts that these JSON messages should be interpreted in.” And so that is one of the tools I think is one of the most underutilized and versatile tools of Domain-Driven Design. And one of the things you’ve asked me what I would change about the book, I said the same thing five years ago, I would take the bounded context stuff and somehow introduced it in the first chapter to the book. But I would urge people to start thinking about that stuff, maybe read that part of my book.
Floyd’s full question: I think we’re also seeing SOA composite applications even notable examples like Amazon.com, the retail site, Facebook, large scale size like InfoQ.com, where you’re actually having different parts of the page being rendered and composed by completely different services in the backend and the website is almost like an SOA composing the services together in one view. What do you think about that? It seems to be an emerging architecture for really large scale size?
Eric: Yes, well, almost kind of mashups of services. Well, for one thing I think that anytime you have these kind of services and you need in the same sense I was just saying about JSON, you need to have the concept the bounded context, I think. So it makes more sense if you think about it that way because you can’t just look at the stuff going in and out of the service as just strings and numbers, but that’s obviously not what the intention is, so it’s meant to be meaningful information going in and out of there and it takes on its meaning within the context. You might have several services that are basically published together, not physically together, I don’t mean as some kind of single deployed unit, but I mean as in these all sort of speak the same language, have the same meaning for certain concepts.
And then, even if you end up presenting those different things to a user and sometimes you’ll put things on the same screen, perhaps, that are from different contexts and then you have to be a little mindful of “Is it going to confuse the user if over here something means one thing and over here it means another?” But I will say this, people are really good at inferring context and switching compared to computers which you know they just aren’t, they can’t do it at all, so the bounded context idea is more important when you’re making things work right. When you’re presenting it to users, all you need to do is give them enough clues to understand how to interpret what they’re seeing. So we have over here, I’m kind of using a term in this way and over here I’m kind of using it that way, but if there’s enough context around it so that I can as a human understand what it means, then fine, that’s what we’re good at. So I think that’s kind of how I would sort that all out.
You know, I started out in SmallTalk and in SmallTalk you had an image and the image was sort of this big memory space in which objects lived and it could be stored onto the disk although, and there was a rigidity to it. But I guess what I’m saying is that this is kind of an abstraction that feels very comfortable to me that I’m not worried about where these things are, the difference between disk and memory. Of course, it’s funny because at the same time we’re talking about all the NoSQL stuff, which it’s almost always persisted in a storage medium of some kind. So it’s almost pulling in a different direction I think. If we had had huge in-memory stores, the objects would have been generally more successful, but when you tie it to relational mapping and other such things, you get the impedance mismatch. So if you want fast, nice, crisp objects, put them in memory by all means. I like it.
There have been a lot of certain schools of design in the past. There is, you know, and I talked about a lot of these had influenced me in the old days like Design-by-contract, Responsibility-driven Design, and a lot of such things. And then the patterns movement and documentation of patterns and all these things, but I think right now, that the way people are expressing these are more through frameworks that embody a philosophy or a programming language that embodies a philosophy or a database that structures information in a certain way. And so, it’s almost like these are the alternative to the book that lays out a philosophy. That’s the way people are expressing things right now. At least, that’s what I’ve been paying attention to and enjoying. And so, I think those are the big influences which we already discussed to some extent.