Leaking Value Objects from your Domain

Value Objects are a great way to explicitly capture concepts within your domain. Value Objects are immutable, always in a valid state, provide behavior, and are defined by their value. This sounds a lot like Messages (Commands, Events) that are also immutable and should be in a valid state. However, exposing your Value Objects by using them within Commands or Events can have a negative impact on your ability to evolve your domain model.

🔗 EventStoreDB

💥 Join this channel to get access to source code & demos!

🔥 Don't have the JOIN button? Support me on Patreon!

0:00 Intro
0:47 Value Objects
2:11 Examples
4:07 Leaking Value Objects in Messages

#softwarearchitecture #softwaredesign #ddd

[gpzim]

Fantastic. Love content about defining what things are, what they are for and specially what they are NOT for, like value objects as a way of exchanging data across boundaries.

[JarrodSwords]

I've literally been struggling with this concept for the last few days. It seems so natural to allow a message to contain a value object if you think of a message as a domain-level concept. But that would come with the catch of each context needing to have its own representation of the message itself b/c of the leak you described. Thanks!

[aaaarvil]

I learned the hard way of not putting value objects in events, just a small change on the value object caused subscribing services to send out corrupted events. Good thing it's not in production.

[craigmunday]

Seems like some Domain Value Objects are really Domain Primitives.

[louisstekhoven-smith]

What about DTO's?

I have some data a repository needs to get from the DB, however it is stored as a json string.

Should we do some work in the repository and have it return a more useful dto, or just get the json and do the mapping in the application service layer?

Either way I don't feel like we are leaking the domain.

[xavierlevaux]

Don’t make your domain leak outside your bounded context.
The objects you use to communicate with the outside are contracts. You don’t want to couple your domain in a contract with the outside. It would make your domain unable to freely evolve.

[codiguard]

Great video, thanks! I remember that in one of the older videos you were talking about book/course about properly architectured monolith, is this already available?

[LuisdelCampo_guichosun]

Excellent as always. Are DTO objects same thing?

[ВалентинГербей]

Thx for the video! What do you think about using value objects for each primitive except bools and dates? When is it useless? And What about events for event sourcing or other events within service boundary kind of “internal” events, is it good to use value objects there?

[ToeShimmel]

I'm pretty new to c# but why are you using a "record" type instead of "struct"? Is it because record has built in serialization? Thanks

[tomasjablonskis]

It would be interesting to see how authorisation and authentication is handled in DDD based system. Is the logic (services/commands/etc.) separated into its own Bounded Context? If so how is access control handled in other Bounded Context? Is crossing the boundary between BCs every time we need to check permissions that live in Identity & Access BC a problem? Is authorisation and authentication even a Domain concern?

[chrismoutray]

I like this, but now thinking...What about string properties that don't have any business rules expect that they must be set; would you continue with methods to enforce this or explicit value object type for each or maybe a more generic type like 'NotNullString'. - great content, keep it up :)

[marna_li]

Great point! Since I started to think about how I write code, I also have started to separate my domain objects from the DTOs.

By the way, what is your opinion on JSON Patch? And what are the pros and cons? To me it does not seem like it is not applicable when not mapping resources to domain objects - for example in a behavior-centric API.

[thedacian]

Hello.What will happend if a user makes a type when entering an address, does 'it worth to make Address immutable, I mean each time the user changes an address we will recreate another value object right? Thank you!

[syedib]

Can we use record Type as Value Object ?

[glennarens]

Have you ever done a video about primitive obsession?

[MateuszNaKodach]

What about DomainEvent? Would you place ValueObjects inside them?
What I mean is for example a functional approach, where you have method like decide with declaration like this:
```List<DomainEvent> decide(List<DomainEvent> previousEvents, Command command)```
In such case, decide is your domain logic. DomainEvents are, of course, parts of the domain.
It's strange to accept as input to domain / return from domain primitives instead of ValueObjects.
Or would you create Domain and Application layer representation of each Event and Command and then map between them when necessary?