Is there any concept in DDD about shared value objects

Question

I need to know about how to use shared value objects in DDD Eg?

If i have two aggregates roots called Registration and Admission, both this aggregates consuming a value object called Address. even though my ubiquitous language are different (Admission address and registration address) the model of this Address object are same ( i meant it has common properties). so i decided to move this value object from both this aggregates roots to common place in my context ( Say SharedValuess). I like to know this practice is good or there any matured method available to handle this type of situations .

NB: This post may against the rules of Stack overflow because its answer is opinion based , but i didn't find any other active forum to ask this question.

Ephemeris

Answer 1

There is a pattern called "Shared kernel". It helps to avoid code duplication and usually used for bounded contexts integration. But I would recommend to keep it as little as possible to avoid leaking logic from bounded contexts. I think in your case it would be a right decision to keep it shared unless you will need to have some differences in your address models for each of bounded contexts.

Nuclide

Shared kernels are expensive to maintain, often not worth it. Don't stare yourself blind on DRY - allow your models to grow autonomously. – Mehalick

@JefClaes, agree with that. Especially when you need to distribute dlls between different separate systems. The rule of thumb - put class in shared kernel or not - is that class should be changed very rarely. If a class has dynamically changing API - it should not be included in shared kernel. So, value object like address may be a good candidate for shared kernel. – Nuclide

I don't get how VO can be shared since it's immutable. On any change to that VO, you would have to explicitly assign it to all objects that are sharing it, so is there any profit to that? – Encephalography

@RafałŁużyński by "share" they do not mean at Runtime, they imply share the code. More in the context of reuse it/DRY – Strontian

But imo OP was talking about sharing value, not code. – Encephalography

Answer 2

You having such dilemma might be an indication of something wrong with the model (UL). I would consider maintaining address in one of the two aggregate roots and reference this aggregate root 'by identity' from the other aggregate root.

Aggregates in Domain Driven Design

Magnoliamagnoliaceous

it violates the principle of data locality, and lead to high coupling between contexts when this is not needed – Akiko