In DDD, the value object is used when your entity conceptually does not have an identity and it is all about the data. Now the question of something being a value object or an entity - where we care about the actual Id - is a business question but think about an address in a ordering management system where a customer has addresses. You probably don’t care about the address as something on its own, so you don’t care about it’s identity and as such, two addresses are the same if their values are the same. Another away about the value object, is that it is immutable, meaning if you want to change an address, you need to create a new one and replace an existing address as it is not possible to change an existing address.Continue reading
You’re going to think I’m jumping on the F# bandwagon as well. Well kind of but that’s not the point of this post. The thing is, people ask me all the time: Why should I even care about F#? I have my own C# language that I love, why go through the burden of learning another language, and more importantly, another way of thinking, as functional programming is not only about the language but more conceptual way of thinking.
In this series, I’m going to write about some of the challenges we’ve been facing with DDD. If you want to adapt DDD on .NET stack, this hopefully will be useful for you. Along with concepts I’ll talk about what works (or doesn’t) well with EntityFramework, but most of it will still be useful with other ORMs - or even without one.Continue reading
- page 1 of 1