DDD naming: Domain Object

Question

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? :)

Answer 1

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.