5

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?

Nabil
  • 71
  • 1
  • 4
  • @ObsidianAge this question is a poor fit over there for the same reasons as here. Please abstain of recommending sites you're not familiar with. See **[What goes on Software Engineering (previously known as Programmers)? A guide for Stack Overflow](https://softwareengineering.meta.stackexchange.com/q/7182/31260)** – gnat Aug 06 '19 at 13:45

2 Answers2

9

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: turns up fewer questions with authoritative answers than, for example .

Community
  • 1
  • 1
VoiceOfUnreason
  • 52,766
  • 5
  • 49
  • 91
  • 1
    Thank you for this explanation. But I don't see how that is different from the common understanding of an entity in databases and data models. Stating that entity in DDD is not an entity in a data model does not help understand DDD - actually, if that is true, then generations of designers would reject DDD, based on the fuzziness of concepts. Can you narrow down your answer to what the differences are? Please note that persistence is not necessary for either way of understanding entity - although frequently is the basis for the distinction. As in databases, you use factories and repositories. – Nabil Aug 06 '19 at 13:24
5

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.

Louis
  • 1,194
  • 1
  • 10
  • 15