I attended a Webinar today by someone quite famous and respected author, lecturer, and expert in software engineering, architecture, and design. The webinar topic was "Incremental Architecture". This luminary stated that the concept of an entity in DDD has nothing to do with the concept of entity in databases. It was an unfortunate choice of term by Eric Evans in his original 2003 book. I was not satisfied with his explanation, and I find that his statement to potentially be very confusing to anyone trying to use DDD in design.
My question: what exactly does the term entity in DDD mean? - if it is not the very well understood and very well defined concept of entity in databases, ORM frameworks, JPA, development frameworks (Spring), etc.
Extensive research in software architecture.
This is a question about DDD strategic design. Coding is not involved.
Not relevant to my question. You allow a topic tag about DDD, which is a design approach, not a coding approach, yet you insist on having code-related questions. How is DDD related to coding?
My question: what exactly does the term entity in DDD mean?
Evan's defined entity in Chapter 5 (A Model Expressed in Software) of Domain Driven Design.
Entities (a.k.a. Reference Objects) ... are not fundamentally defined by their properties, but rather by a thread of continuity and identity.
An object defined primarily by its identity is called an ENTITY.
An ENTITY is anything that has continuity through a life cycle and distinctions independent of attributes that are important to the application's user.
It is an in memory abstraction of something that changes over time. It's a temporally varying membership function which for time t maps an identifier to some state. It's used within the domain model to represent things that change.
An example of a entity in a domain model might be... a question on stack overflow.
The meaning of "entity" in Domain-Driven Design
When somebody edits the text, or changes the title, or downvotes... it's still the same question, in that there's a progression from what the text used to be to what the text is now. It changes over time from having this text to having that text.
A simple entity in a domain model might map to a single row in a relational database, but it won't necessarily do so. More precisely, we might save the current state of the entity in a single row. But if that state includes a collection, then it is likely that the state will be distributed across multiple rows, perhaps in multiple tables.
You allow a topic tag about DDD, which is a design approach, not a coding approach, yet you insist on having code-related questions. How is DDD related to coding?
If The Source Code is The Design, then the design necessarily includes coding. The middle section of the Domain Driven Design book, which gets most of the attention, covers topics in modeling domains in code.
Truth be told: domain-driven-design turns up fewer questions with authoritative answers than, for example java.
An entity is a type that has an identity. The id could be anything but it has to be unique to the system and in fact depending on the subdomain you are in, the identity/entity might change.
For example:
A database might have a "User" Table that has fields "firstname", "lastname" e.t.c.
In DDD for an ecommerce application's purchase subdomain, you might have "Shoppers". These Shoppers might have an id of "firstname lastname". In the "Shipping" subdomain of the same application, you'll also have the concept of a "Shopper"(or buyer) but this time the identity of the shopper might be "Full address".
So, where a database entity is nothing more than a grouping of data with an identifier, A DDD entity is a concept. The concept is pertinent to the system, described in the ubiquitous language and is the central actor around which many functions in the domain will operate. The data that populates a DDD's entity usually comes from several datatable entities.
Related
Consider certain kinds of objects involved Domain-Driven Design (DDD): Entities, Value Objects, Domain Events, and Domain Services.
Which of these are considered to be Domain Objects? And are there other names for abstractions that encapsulate a subset of those?
I can identify various abstractions that are useful to have when talking about DDD or domain models:
Entities and Value Objects. I often find myself mentioning "Entities or Value Objects". Most notably, these are the ones that model the domain's state. In contrast, Domain Services are stateless, and I would argue that Domain Events merely reflect information about how the domain came to be in its current state.
Entities, Value Objects, and Domain Events. These may all contain or represent data, whereas the Domain Services only define behavior.
All objects recognized by the domain model. It is useful to be able to talk about parts of the domain model in general, as opposed to concepts outside of it.
It's interesting how even Stack Overflow's domain-object tag has a confusing definition:
Domain Objects are objects made for dealing with the domain logic at the Model layer. These objects generally simulate real (or virtual) items from real-life: Person, Post, Document, etc.
The initial definition, focused on "dealing with the domain logic", leans towards "all objects recognized by the domain model". The examples then lean towards "Entities and Value Objects".
DDD hammers on a clearly defined, unambiguous Ubiquitous Language, and with good reason. Shouldn't it lead by example? :)
Which of these are considered to be Domain Objects?
All of them. They are "objects" that implement our domain model. In the original DDD text, Eric Evans also used the phrase "model elements".
The distinctions between them are largely a consequence of the constraints of the Java language. You wouldn't need "value objects" if you could just create bespoke values; you wouldn't need "domain services" if you could just pass around the capabilities you need. You wouldn't need "domain events" if you have "messaging" as a ubiquitous construct, and so on.
DDD hammers on a clearly defined, unambiguous Ubiquitous Language, and with good reason. Shouldn't it lead by example? :)
Well, part of the riddle is that these patterns are part of a general purpose language, and one of the central messages of DDD is that you shouldn't allow general purpose concerns to distract you from the domain itself.
That said... yeah - it would be better today if Evans had a rich understanding of these ideas eighteen years ago, and was able to introduce the best language and provide counter measures to prevent semantic diffusion.
Im new to learn DDD concept and i cant understand something.
1-What difference between Context Map and Bounded Context and SubDomain?
2-How to recognize relation between Bounded Context ?
As said in the comment, this is a wide subject, and very important in DDD. It is the strategic part of DDD. Anyway I will try to answer your questions with an overall explanation:
DDD is about understanding and distilling the domain of the problem we want to solve. It is a continuous process of learning about the domain, talking to the domain experts. All people (developers, business people, etc) speak the same language. This language is used everywhere (conversations, documentation, source code, ...). It is called the Ubiquitous Language (UL).
The problem domain may have different areas of functionality, which would be domains too. They are the subdomains. So a subdomain is a subset of the problem domain. It is like splitting the problem into smaller subproblems, and a subdomain would be the domain of a subproblem. There are 3 kinds of subdomains:
Core: The point of distillation is to discover the subdomain that has value for the business, i.e., the one that will make your product better than others of the same kind. Such subdomain is the "core subdomain". For example, in "project management", the "task assignement" would be core.
Supporting: It is specialized in some business aspect that helps the core functionality. For example, in "project management", a "calendar" (for marking tasks delivery dates).
Generic: Functionality that maybe needed by any kind of application. For example, authentication and authorization of users.
Subdomains belong to the problem space.
To solve the problem, you model the subdomains, and you create bounded contexts (BCs). In practice, a BC is an autonomous application that contains the software model of a subdomain. A BC has its own UL. It is the context on which a term of the UL has a meaning. UL and BCs are the most important things in DDD. UL drives the BCs identification.
Ideally, you should align 1:1 the subdomains of the problem space with the BCs of the solution space, i.e., you should have a BC for each subdomain.
A team can develop one or more BCs, but a BC should be developed by just one team.
BCs belong to the solution space.
Context Map: It is a drawing that shows the BCs, and the relationships among them. Every relationship is classified in one of the following patterns:
Partnership
Shared Kernel
Customer-Supplier
Conformist
Anticorruption Layer
Open Host Service
Published Language
Separate Ways
Big Ball of Mud
Recognizing which pattern to apply in a relationship it will depend on the particular case you have. Some things that you have to consider are:
The 2 teams collaborate together.
One of the teams doesn't care about the other one.
The teams can negotiate.
The teams are independent.
Changes on a model (upstream) affects to the other model (downstream).
As #Augusto mentioned, this is a couple of chapters in the blue book, but here goes.
The domain model is found in the business rules and how people talk but a simplification of it is captured in code. Certain naming is consistent and the necessary invariants are enforced in the model.
A bounded context is mostly conceptual (might be a namespace, module, project in code as well...). It is the intention to keep a domain model consistent within it. So within the context, a certain ubiquitous language is used. And a model need only serve the needs of THAT context. It is the boundary in which the model can be used. In terms of recognizing these relationships? Some might be subtle but most are not. At least some people in the team will want to "avoid duplication" by unifying the model... so that is a clear indication that there is a relationship. Names are often the same or similar... or could be the same but one is better suited to one domain and another to another domain.
A context map is a bit more of a project management tool. It is a map of how different contexts (and the models within) relate to each other. In an Ordering Domain in an e-commerce system you may have a product. It would lead to A LOT of complication trying to have a unified Product in a model that spanned Ordering, Payments, Content for the website and Inventory domains (for example). So each of those domains should have a separate model. The context map is a diagram and related documentation that relates these bounded contexts together since there would be relationships and translation of data across from one model to the next, as an order flows through the system.
The last element you asked about is a subdomain. Here you probably are referring to a generic subdomain. Personally, I think the name is a little confusing. It makes it seem like a subset of the model. Maybe this is on purpose but I generally think of them as their own domain, just one that is not central to the business's proposition. For instance, if the aforementioned e-commerce company was known for its same day or next day delivery, then they probably shouldn't buy an off-the-shelf solution to inventory and shipping management. On the other hand, if they were focusing on a market that just wanted the cheapest deal but didn't mind waiting a few days, then that would be a perfect candidate for a generic subdomain.
My DDD glossary which has plenty of links at the bottom to more detailed articles.
If you are serious about learning this subject and can get your hands on some books:
Domain-driven Design by Eric Evans
Implementing Domain-driven Design by Vaughn Vernon
Domain-driven Design made functional by Scott Wlaschin (my favourite)
I read this article today and am trying to clarify some things. Does this article mean that model objects should contain business logic?
For example let us say that there is a Student object that we retrieve form the database via Hibernate. Does this article say that the Student object should contain business logic as well rather than having only getters and setters?
Disregard the date, what Martin Fowler states is as relevant today as it was eight years ago. Fowler does not state that you should mix persistence into the domain objects, quite the contrary:
"It's also worth emphasizing that putting behavior into the domain objects should not contradict the solid approach of using layering to separate domain logic from such things as persistence and presentation responsibilities."
You should read the article again, because the article describes this anti-pattern extermely well, but I shall try to summarize it for you in the context of what you are asking:
If you are to create a domain model, yes your domain objects should contain business logic as well as state, and changes to the state of your domain entities should be done through methods which convey business meaning. The anemic domain model is an anti-pattern because you incur the cost of an extra layer of classes but you are not reaping the benefits. Why bother with a domain layer which you have to map against the database when it convey exactly the same intent as you get from using an active record style approach (dataset, etc)? So the article does not say that you should have a "student-object", but it states that if you do, you should definitively add state to that class.
The point in the article about not having a set of objects to represent your model if you don't also model your domain can be a bit confusing due to the technologies available today. There are great tools out there which can effortlessly move data between a set of POCOs and the database (Nhibernate, EF, Simple Data, Massive, Dapper, etc) so in that retrospectiv I would say that you would probably end up with a set of "entities" in most solutions today, the real difference being whether this is just a database model or a real domain model.
I'll close up by showing you an example of the interaction between a domain entry point (command handler) and a domain model. The method shown below lives in a command handler which consumes a request to change something in the domain. Notice that the layer-ontop-of-your-domain-code simply gets the domain entity and calls one method on the domain? Thats an important point because the workflow we are modelling is fully encapsulated in the domain, not in the layer-ontop-of-your-domain-code or anywhere else:
public void Handle(AddEmailAddressForAlerts command)
{
var agent = _repository.GetAgent(command.AgentKey.AgentId);
agent.AddEmailAddressForAlerts(new EmailAddress(command.EmailAddress));
}
Notice the date - the citation is over eight years old.
Martin Fowler is obviously a very smart guy, and I like the article's point, but take it with a grain of salt. Encapsulating state and behavior together is a good thing in general, but it should be balanced against layering considerations. Persistence isn't the same thing as business logic. I'd still have a separate persistence tier; I wouldn't put persistence in a model object.
Dogma should be challenged in all its forms. Be aware of other people's ideas, but think for yourself.
In Domain Driven Design how do you document key aspects of your model so that it can be communicated with your team and so that it can be developed over time?
By Key Aspects I mean:
ubiquitous language
aggregate roots
Entities / Value Object
Invariants
In the code. And in conversations. And on whiteboards, and documents, and models...
The key points are (1) ubiquity and (2) consistency. So if a domain expert talks about "Assessing a Loan Application", you should have code that syntactically and semantically matches that concept. So you might have LoanApplication.Assess(). You wouldn't have ApplicationManager.QualifyApplication() or similar.
So you would minimally record the language in the code. You may also choose to record in documentation and/or diagrams. You will also use on whiteboards and in discussions. But in all cases it's the same language.
hth.
I am quite new with DDD and would like to know about any pitfalls you might want to share. I will summarize it later for more newbies to read :)
Thanks
Summary so far:
Anemic domain model where your entities are primarily only data bearing and contain no business logic
Not using bounded contexts enough
Focusing too much on patterns
There is a good presentation on this topic as well here (video).
Probably the most important one: not grokking the central, fundamental principle of the Domain Model and its representation in Ubiquitous Language. With the plethora of technology options around, it's very easy for your head to fill up with ORMs, MVC frameworks, ajax, sql vs nosql, ... So much so there's little space left for the actual problem you're trying to solve.
And that's DDD's key message: don't. Instead, explicitly focus on the problem space first and foremost. Build a domain model shorn of architectural clutter that captures, exposes and communicates the domain.
Oh, and another one: thinking you need Domain Services for everything you can do in the domain model. No. You should always first try to put domain logic with the Entity/Value type it belongs to. You should only create domain services when you find functions that don't naturally belong with an E/V. Otherwise you end up with the anaemic domain model highlighted elsewhere.
hth.
One of the biggest pitfalls is that you end up with a so-called anemic model where your entities are primarily only data bearing and contain no business logic. This situation often arises when you build your domain model on top of an existing relational data model and just make each table in the database an entity in your domain model.
You might enjoy presentation of Greg Young about why DDD fails.
In short:
Lack of intent
Anemic Domain Model
DDD-Lite
Lack of isolation
Ubiquitous what?
Lack of refinement
Proxy Domain Expert (Business analyst)
Not using bounded contexts enough. It's toward the back of the the big blue book but Eric Evans has gone on record as saying that he believes that bounded contexts and ubiquitous language are THE most important concepts.
Similarly, people tend to focus too much on the patterns. Those aren't the meat of DDD.
Also, if you do not have a lot of access to domain experts you are probably not doing DDD, at best you are DDDish.
More concretely, if you end up with many-to-many relationships, you've probably designed something wrong and need to re-evaluate your aggregate roots/contexts
Only adding to what others have already said;
My personal experience is that people often end up with an anemic model and a single model instead of multiple context specific models.
Another problem is that many focus more on the infrastructure and patterns used in DDD.
Just because you have entities and repositoriesand are using (n)Hibernate it doesn't mean you are doing DDD.
It's not from my personal experience with subject, but it was mentioned for a couple of times in DDD books and it's what I've been thinking about recently: use Entities when you really need identity, in other cases use Value Object. I.e., Entity pattern often happens to be the default choice for any model noun, and it's not the way it should be.
Beware of the Big Ball of Mud.
One of the pitfalls of domain driven design is to introduce ambiguity into a model. As explained in the article Strategic Domain Driven Design with Context Mapping:
Ambiguity is the super-villain of our
Ubiquitous Language
This may happen when two distinct concepts share the same name, or when the same concept can have different uses. It may be necessary to
expose the domain structure in
terms of bounded contexts in a context
map
If a model is used in too many different ways, or has too many responsibilities, it may be a sign that it should be divided.