The questions below are more about semantics and concept than anything. 1) In regards to CQRS, are Commands considered part of the domain? I apologize if the...
1) commands are not part of the domain. They are packaged separately. Application services act to translate. 2) never heard the term domain query before. Link?...
Thanks for the reply Greg. Nevermind the link, there were just a few related question on StackOverflow about it. However, here is why I ask... As most of you...
If Model Driven Engineering means that development processes are governed by model contents, two options are possible: * Language translation: meta-models...
First of all - hello everyone, and thank you for helping others discover the wonders of DDD. It's fantastic how many people are willing to volunteer their time...
I have been reading 'Domain Driven Design' lately and have just finished the chapters on repositories. I have a question that I cannot seem to understand. ...
I am fairly new to DDD and am learning myself. According to DDD an entity should only carry fields that establishes its identity. A true identity never...
(also beginning DDD adept here) For domain modeling it helps to explicitly not think initially about how you're going to store application state. This will...
That's a recurring classic: if addresses are not managed on their own, e.g for logistics or law enforcement purposes, their identity and semantics are local to...
Which one ? Assuming no domain logic, there is a collection of addresses, and this collection is part (aka composition) of the Customer entity. It's easier to...
Hi, I'd say DDD is totally transparent as by how the system is deployed. DDD is about how you think of and organise your domain logic and the techniques you...
DDD is about modeling behavior not data. The data that is encapsulated within an aggregate should only be what is required to be consistent and needed for the...
That would be perfect if stand-alone and self-contained applications were the only ones to be modelled. Unfortunately business objects are usually shared. ...
"Reusable" business objects is a fallacy. DDD is not about creating "Generic" and "Reusable" code. It's about modeling specifically what the business wants....
In DDD every bounded context has its own business objects. This actually makes every BC self-contained. As far as I am concerned, that is the core of what DDD...
Perhaps that is a large part of the problem? ... -- Le doute n'est pas une condition agréable, mais la certitude est absurde. Perhaps that is a large part of...
Thanks Jorgen, I am aware about that difference, but the thing that triggered that question is that in some cases (rare cases) the Deployment Plateform ...
So based on the reading of DDD book it appears that the author proposes starting with identifying entities and value objects and then figuring associations....
It’s been a while since I posted on anything, but I have a relevant story. I’m still kind of a noob, so take this with a grain of salt. Not too long ago, I...
If this is the interpretation you are comfortable with try it out. I have seen some very successful systems built that way and some not so successful. ... -- ...
Hi, My most basic rule is to stay with entities and value objects that can be found in the ubiquitous language (UL), i.e. things that the domain experts talk...
Hi, In most domains I've seen Address is a typical value object, not an entity, and as such it is only kept internal to the customer aggregate, as any other...
Regarding what Remy said, I’ve seen this in law enforcement programs, as well as EMS and 911 dispatching services. Addresses will be maintained on their own...
Does maintaining addresses on their own make them entities instead of values? And what would you maintain? Are they just being validated? IMO addresses are...
Having worked in law enforcement I can assure you that there is a difference between a case management perspective and a property/evidence room perspective of...
Here's a question that been nagging at me a while. Please note that I've not actively been writing real code, just doing a lot of intellectual thinking about...