Value object with identity? about iddd_samples HOT 5 OPEN

Thanks for the reply!

So basically identity is enforced by ORM and not the domain, right? I understand that it gives convenience to configure ORM to handle mapping between domain and persistence entities without writing translation code manually, but does not it leak abstraction? I say leaky abstraction cause, ID is not used on Value Objects in terms of business and there can exist different repository implementation which can store and retrieve collection of value objects without enforcing them to have identity. I understand that we might "say no to perfect code" sometimes in favour of some another benefit (like convenience in this case) and I don't see any problem as long as team respects Value Object semantics and does not access them directly via ID, but is not possible to improve this somehow? Or is it a thing I should really worry about?

from iddd_samples.

It's for special cases of Value Objects that must be persisted through an
ORM as entities in the database. One example is a collection of Values.

On Aug 28, 2016 8:13 AM, "Beka Tsotsoria" [email protected] wrote:

Can anyone explain why IdentifiedValueObject
https://github.com/VaughnVernon/IDDD_Samples/blob/master/iddd_common/src/main/java/com/saasovation/common/domain/model/IdentifiedValueObject.java
has identity? Does not it violate definition of Value Object? Is it domain
identity or persistence identity?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#22, or mute the
thread
https://github.com/notifications/unsubscribe-auth/ACg87MQU0FO98aEeXMBIT6Ksjvu_mIA9ks5qkZd1gaJpZM4Ju7uf
.

from iddd_samples.

It's one way to solve the particular problem, a way that is discussed in my
IDDD book. There are other ways as well.

On Aug 29, 2016 3:04 PM, "Beka Tsotsoria" [email protected] wrote:

Thanks for the reply!

So basically identity is enforced by ORM and not the domain, right? I
understand that it gives convenience to configure ORM to handle mapping
between domain and persistence entities without writing translation code
manually, but does not it leak abstraction? I say leaky abstraction cause,
ID is not used on Value Objects in terms of business and there can exist
different repository implementation which can store and retrieve collection
of value objects without enforcing them to have identity. I understand that
we might "say no to perfect code" sometimes in favour of some another
benefit (like convenience in this case) and I don't see any problem as long
as team respects Value Object semantics and does not access them directly
via ID, but is not possible to improve this somehow? Or is it a thing I
should really worry about?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#22 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACg87KmWjjx_knQQWXcFnTvneiewUEZZks5qk1dfgaJpZM4Ju7uf
.

from iddd_samples.

After little googling I came across to an idea where one suggests to extend subclasses of IdentifiedValueObject like GroupMember at the persistence layer and declare ID (and potentially other persistence related fields) on this extended object, this way IdentifiedValueObject will not be needed anymore and domain layer will be free from the persistence concerns.

I'll definitely read IDDD sooner or a later!

from iddd_samples.

@sevteen I was thinking the same whereas actually by declaring ID in the extended object directly, you just added persistence data in your domain. By using the IdentifiedValueObject, you don't explicitely have to add this knowledge. Moreover the id being private in the super class, you never come accross as a developper in your child OneToMany value object.

from iddd_samples.