deg (3) [Avatar] Offline
#1
I usually refer to my domain-primitives library as my [i]vocabulary[i] since they are core domain concepts. In a port and adapters architecture, that vocabulary is shared across layers. Solving the cumbersome mapping argument of A into A' into A'' that is often an argument against the separation of layers. Doesn't vocabulary capture the domain meaning more than library? Or does it have other connotations? Just a thought.

A connotation the name domain primitives also have is that they should be small, because of the name primitives. But if they are immutable, guard their constraints and are always consistent when they exist, is there a problem/limit with the size of one? If it still contains a single clear concept? For example orderInfo with a lot of items that need to received by before it can become an actual order and evolve into a shipment.

Loving the book by the way.

Dan Bergh Johnsson (11) [Avatar] Offline
#2
Hi Guido

From a philosophical perspective I agree that "vocabulary" would be a neat term. It captures well the important aspect that a domain model builds a language. Us using "library" is a "programmer-friendly" terminology as a "domain code library" is something we think many programmers easily relate to. Even-though, in discussion with more DDD-inclined developers I would probably also talk about "vocabularies" or "sub-languages" or some other linguistic-inspired term.

The name "Domain Primitive" started of as an analogy to "language primitives" as a stepping stone to build domain-focused solutions. But we certainly agree with you that the use in not restricted to "just really small things". We touch on that idea in chapter 7 when using the same idea on an "OrderSnapshot", something that is definitely not "a really small thing".

Glad to hear you enjoy the book. We have had lots of fun writing it (well ... and a lot of work) smilie

Dan



deg (3) [Avatar] Offline
#3
It is a discussion I've had recently. The argument went that it isn't a domain primitive because it isn't small. Coming from a java env where primitives are indeed small building blocks, but domain primitives are also building blocks. If it fits a single concept and the requirements for domain primitives... The name "domain primitive" does fit the bill in the sense that they are the building blocks for your domain. But perhaps be aware of other connotations that come along with the term primitive.

Do you equate domain primitives with entity snapshots? An entity snapshot can exist out of domain primitives, but is it a primitive itself? Does it need to do validation when it is created? I'm approaching it at the moment from a more general design perspective than security. Or is an entity snapshot a special case of domain primitives?
Dan Bergh Johnsson (11) [Avatar] Offline
#4
deg wrote:It is a discussion I've had recently. The argument went that it isn't a domain primitive because it isn't small. Coming from a java env where primitives are indeed small building blocks, but domain primitives are also building blocks. If it fits a single concept and the requirements for domain primitives... The name "domain primitive" does fit the bill in the sense that they are the building blocks for your domain. But perhaps be aware of other connotations that come along with the term primitive.

Do you equate domain primitives with entity snapshots? An entity snapshot can exist out of domain primitives, but is it a primitive itself? Does it need to do validation when it is created? I'm approaching it at the moment from a more general design perspective than security. Or is an entity snapshot a special case of domain primitives?


Here comes a big disclaimer that we are out on a philosophical tangent that I think is really interesting, but where not necessarily every single aspect is completely thought through.

When discussing the size of domain primitives, one thing we really think is important is not to make them too small. It is important that the domain primitive makes up a conceptual whole that makes sense in the domain. Taking the money-example: the amount is not enough of itself to make up a sensible domain concept - it needs the currency to become a conceptual whole. This is an error we have seen on several occasions. It is important that the concept is native to the domain, and consists of a conceptual whole.

Now, an order snapshot - is it a domain primitive? Perhaps. Design-wise, its structure fits well with the other domain primitives (like Money). It forms a conceptual whole, and validation is an important part of it - it cannot be created in an inconsistent way. Perhaps it could be argued that it isn't *really primitive* in our pretty sketchy domain. But we think it clarifies more that it confuses, so we have applied the label "domain primitive" even to an object that could be argued to be composite.
Daniel Sawano (1) [Avatar] Offline
#5
deg wrote:A connotation the name domain primitives also have is that they should be small, because of the name primitives. But if they are immutable, guard their constraints and are always consistent when they exist, is there a problem/limit with the size of one? If it still contains a single clear concept? For example orderInfo with a lot of items that need to received by before it can become an actual order and evolve into a shipment.

Loving the book by the way.



You're right that if it's a conceptual whole then it doesn't matter how big the domain primitive is. I think the following quote from chapter 5 in the book captures it pretty well:
A value object so precise in its definition that it, by its mere existence, manifests its validity is called a domain primitive.


The key here is the term value object. This means that what applies to a DDD value object in terms of how you design it also applies to a domain primitive.