Introduce @Identifier in DDD annotations

[odrotbohm]

Although not an original concept within the DDD book, an identifier is already part of the type based domain language in the DDD module. For symmetry reasons it's reasonable to also allow to express the concept as annotation. We went for Identifier (over Identity) for the following reasons:

1. Symmetry with the already existing Identifier interface in the type based language.
2. Contrary to the type based approach, the annotation is to be used on a field that constitutes the identity of the owner class. It is not the identity itself.

[hschwentner]

After thinking about it again, I've changed my mind and prefer Identity as a name now. While it is true that the field is not the identity itself it also true that the class is not the entity itself. The class is a model for the entity and the fields is a model for the identity. Since "identity" is a term widely used in the DDD literature and therefore familiar to developers I'm voting for that variant.

I would love to hear opinions from the community! @cyriux @NTCoding @VaughnVernon @ericevans0 : what do you think is the best name for this annotation—Identifier or Identity?

[VaughnVernon]

Hi @hschwentner My favorite name is "Don't Use Annotations," but somehow I suspect that's not the answer you wanted from me. 😃

[VaughnVernon]

BTW, in terms of word use, this might provide a decent line of reasoning:

https://www.merriam-webster.com/dictionary/identifies

To identify (verb) something is to establish its identity (noun).

The definition of identifier reads a lot like what I consider an identity, but its use in software is generally as a programming language token such as a keyword, a built-in type, or a variable name. In fact these are themselves entities of the language:

https://en.m.wikipedia.org/wiki/Identifier_(computer_languages)

It seems like your intended use is more an identity than identifier.

[hschwentner]

Hi @hschwentner My favorite name is "Don't Use Annotations," but somehow I suspect that's not the answer you wanted from me. 😃

Hehe, your suspicion is right 😉 Anyway, for those who prefer types over annotations the jMolecules do offer a marker interface Identifier, too: https://github.com/xmolecules/jmolecules/blob/main/jmolecules-ddd/src/main/java/org/jmolecules/ddd/types/Identifier.java

[NTCoding]

@hschwentner my initial feeling was that identity is right for the reason you mentioned, that it's an element of the model that represents the identity of the physical/conceptual thing being modelled.

But I wonder if that assertion is always true. Is what we label an identity in software considered to be an identity in the domain?

[odrotbohm]

I am torn. On one side, I see value in consistency between the approaches (the type-based VS. annotation-based model) to avoid having to justify the slight difference in naming, foreseeably a loot of times. On the other hand, I think Vaughn brings up a good point: the identifier actually is the actual value, the token. We annotate the field here, which – by definition – is not the value, it captures it. So, you can argue that the difference in naming stems from the difference in the way, expressing the concept in code works.

[sth77]

For me, Identifier is a better match. I see it as part of the DDD meta model, like „AggregateRoot“ or „Entity“, which you never find in a domain (unless you‘re building a DDD modeling software). In fact it is a subset of the properties of the modeled entity which allows us to identify that entity within the scope of our bounded context. As pointed out above, the Identity belongs to the „real world“ and is only approximated by the identifier.

In this context I noticed that jmolecules forces me to call my identifier „id“ (using the JPA integration), although in the domain I call it for example „part number“. This hurts me more than Identifier vs. Identity, as it directly impairs my model. This point is probably worth its own ticket.

[odrotbohm]

For me, Identifier is a better match. I see it as part of the DDD meta model, like „AggregateRoot“ or „Entity“, which you never find in a domain (unless you‘re building a DDD modeling software). In fact it is a subset of the properties of the modeled entity which allows us to identify that entity within the scope of our bounded context. As pointed out above, the Identity belongs to the „real world“ and is only approximated by the identifier.

Still, we annotate the field, and it's not the field that is the identifier, it merely captures it, doesn't it?

In this context I noticed that jmolecules forces me to call my identifier „id“ (using the JPA integration), although in the domain I call it for example „part number“. This hurts me more than Identifier vs. Identity, as it directly impairs my model. This point is probably worth its own ticket.

That's only true for the type-based model, in which we have to deal with the language means Java gives us. So nothing / nobody is "forcing" you to do anything 🙃. If we want to expose the Identifier from something Identifiable, we have to give the method exposing it a name. You could still name it (the field holding the value) any way you want and expose it under whichever convention you prefer. You'd just need to additionally expose it in a way that matches the interface, yes. If you feel overly constrained by that, you'd have to go with the annotation-based model and by that, trade that freedom of choice in naming against the type safety provided by the type-based model, in particular around associations and the resolution of those.

[cyriux]

I’m late to the party, but I like Identity for the field annotation: it promotes the attention to Identity, using the right word as you say, it documents that the field has this responsibility, without constraining the field name, and being on the field it doesn’t pollute the associated type (which probably doesn’t even have to know it’s used as an identity of another entity).

[odrotbohm]

Thanks, everyone, for the feedback. I think the majority vote (especially among the maintainers) is leaning towards @Identity. I'll tweak the PR to reflect that decision and merge it.