The "Domain Model"

There has been some recent discussion on User Stories, the Ubiquitous Language of a domain, and Domain Models. I have been fairly confused because I am not clear on what folks have meant by the “Domain Model.” Some folks seem to be referring to the true code construct that results from 1) having a user story define some desired behavior, 2) discussion of this behavior, and 3) refinement of the concepts into the code construct.

From the beginning of Evan’s book, I think of the domain model as:

 ”A domain model is not a particular diagram; it is the idea that the diagram is intended to convey. It is not just the knowledge in a domain expert’s head; it is a rigorously organized and selective abstraction of that knowledge. A diagram can represent and communicate a model, as can carefully written code, as can an English sentence.”

Yes, the domain language does drive the model. And user stories drive that original discussion. But the model is not just code. Once discussed, refined, and hammered out, it is these concepts of the domain model that enter the ubiquitous language, whether or not those concepts end up in code.

My $2. I don’t disagree with other folks out there – just explaining what I’ve always thought of the model.

What do you guys think?


About Nelson Montalvo

I’m a software developer who loves .NET, Agile methodologies, Test Driven Design, Domain Driven techniques, and open source tools. Don’t get me wrong, I also like to use a thing or two that Microsoft creates besides .NET itself. :) In my “spare time” (when is that, anyways?) I like riding my motorcycle (, reading, watching movies (lots of movies), working out, and hanging out (good conversation, good beer, good times). Look me up in Facebook, Linked In or Plaxo. My personal code blog is
This entry was posted in Domain Driven Design. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

7 Responses to The "Domain Model"

  1. Jamal Hansen says:

    I generally take the term model literally, as in the hobby of modelling. If I buy and assemble a model of a ferrari, it is not a ferrari, but a simple representation of one that looks and to some degree acts like one. So we take a domain which, by definition, is complex and make a model of it. What we have made is a simplified representation of it. We may increase the realism of the model by using DSL. We could also diagram it, making in essence a model of our model, but in either case the model is the code. Thanks for the interesting post. -Jamal

  2. Joe Ocampo says:

    I was confused as well a while back and I emailed…(I don’t like name dropping but I am in this case.) Eric Evans. I won’t go into the complete discussion but there is one line that has stuck with me since conversing with him and it is this:

    “I usually say the
    code is “an expression of” the model rather than it “is” the model.”

    This clarified my entire understanding of DDD as it helped encourage me that I was on the right track. The concepts weather they are technical or empirical in explaining the domain model are not the model but merely expressions of it. The model is the “idea” of what the domain is trying to solve and all the moving parts.

    The ubiquitous language helps galvanize the constructs of the “idea” by helping the team communicate in common vocabulary towards the “Domain Model”.

    But outside of the Domain model lets not forget the other “D”s in DDD.

    The Domain model helps facilitate the Drive towards a system Design to solve the problem domain.

    The by product of such an endevour is understanding of the system by the team as one whole.

    OK I have crossed the realm of sounding like it is a religion which I promised myself I would never do!!! I must be flogged now! :-)

    The real point in all this is getting people to talk to each other. Agile’s first value is:

    “Individuals and interactions over processes and tools”

    Lets not forget that! DDD is a process and a tool to help ease the communication between individuals. The minute it starts to detract from that, step back and evaluate what you are doing. You may be approaching it incorrectly or it might not be right for your situation.

    I see your $2 and raise you $5. :-)

  3. I will probably get stoned for saying this, but I have yet to read Eric’s book.

    I have read Jimmy Nilssons book, Applying Domain Driven Design and Patterns and it gave me a pretty good idea of the basic concepts of developing domain models.

    That being said, Understanding how to effeciently and properly develop a Domain Model has got to be one of the more complex concepts I’ve tried ever since coming to the programming community some 7 years ago.

    I feel like I understand all the concepts and have it all down, but then someone casts a new light on the whole thing and it changes or rather redirects my understanding.

    DDD is definately an ongoing learning process. This is why it appeals to me so much I think.

    How you explain this above Nelson is how I always thought the Domain should be composed and how the domain language should work into the whole scenario.

    Great post Nelson!

  4. joeyDotNet says:

    I’m right there with ya Sean! A friend of mine (and CB’er) Paul Laudeman bought me both the Nilsson and Evans book as a Christmas gift last year. I was torn between which one to read first.

    So I read the Nilsson book first, which I now think was probably a mistake. I was just so eager to start *applying* DDD before really *understanding* DDD. Always a bad thing. But, I’m finally getting around to reading the Evans book and a lot of things are starting to make more sense to me.

    So, based on what I’ve read so far, I’d definitely recommend reading the Evans book as well.

    Term of the day: Continuous Learning :)

  5. @Joe,

    I agree with you 100% on individuals over processes.

    However, since we are in the corporate machine at work, let’s look at one more quote from Evans. :)

    “Domain experts should object to terms or structures that are awkward or inadequate to convey domain understanding; developers should watch for ambiguity or inconsistency that will trip up design.”

    We have a user story. We begin to have an open conversation of that story. DDD serves as a great way to structure the conversation, although being agile, we always remain open to altering the basic elements of DDD to suit our needs.

    I think the last part of the quote is the important part because it opens up the possibility of having new ubiquitous terms being defined as a result of modeling. Not coding (although it’s possible), but the act of discussing the model.

    In hammering out the ambiguity, we make concrete some new concept, which enters the model and the language.

    Would you agree with that?

  6. Joe Ocampo says:

    Yes I would agree with that conclusion in fact,

    > “…watch for ambiguity or inconsistency that will trip up design.”

    Dave Laribee and I came up with a term for these design trip ups “Distractons”

    You can read more about it here.

    > “I think the last part of the quote is the important part because it opens up the possibility of having new ubiquitous terms being defined as a result of modeling. Not coding (although it’s possible), but the act of discussing the model.”

    It is important not to discount code as being an origin point for a new ubiqoutous term. There have been many times where I start to write my test following the model only to scatch my head as I discover something that is missing, resulting in some new object that can help the domain. CAUTION! Make certain to reengage the team on the new artifact that was discovered. Everyone must agree to the new term to make it a viable artifact of the ubiquitous language. All the code did was bring greater clarity to the domain but not at the sacrifice of altering the Domain to fit the code.

    Does that make sense?

  7. Makes sense to me. Thanks!