I’ve read about CQRS systems that maintain a simple key value store on the command side to represent an application’s state, and others that merely correlate messages (using some sort of saga) and utilise the query store to represent an applications state instead. Either way there’ll no doubt be a persistence technology involved with these … Read more
Here is how I reason about it: Only use inheritance if the role/type will never change. e.g. using inheritance for things like: Fireman <- Employee <- Person is wrong. as soon as Freddy the fireman changes job or becomes unemployed, you have to kill him and recreate a new object of the new type with … Read more
Commands and Events can be of very different concerns. They can be technical concerns, integration concerns, domain concerns… I assume that if you ask about domain, you’re implementing a domain model (maybe even with Domain Driven Design). If this is the case I’ll try to give you a really simplified response, so you can have … Read more
My feeling on this is that domain objects (not domain entities, as that title implies something to do with a database) should not be interfaces unless you have a very compelling reason to believe that you will need to support multiple implementations at some point in the future. Consider that the domain model is the … Read more
I think the term “repository” is commonly thought of in the way the “repository pattern” is described by the book Patterns of Enterprise Application Architecture by Martin Fowler. A Repository mediates between the domain and data mapping layers, acting like an in-memory domain object collection. Client objects construct query specifications declaratively and submit them to … Read more
I think this particular issue can be solved elegantly with a Domain Event.
I agree with a number of the concepts presented in other responses, but I put them together in my code. First, I agree that using Value Objects for values that include behavior is a great way to encapsulate common business rules and an e-mail address is a perfect candidate. However, I tend to limit this … Read more
I would say this practice promotes concentrating your efforts on the ‘problem space’ rather than the ‘solution space’. Driving an emergent solution (the design) by studying and really getting to know and understand the domain. One of the practices (taken from XP) would be the writing of stories that occur in the problem domain. From … Read more
You may want to look into the concept of Command Query Separation. I wouldn’t worry about typed repositories for lookup values, but I’d still probably use DTO type classes over datasets etc… You may want to spend some time reading Greg Young’s blogs starting from this one to the present. He doesn’t talk about filling … Read more
Don’t disagree with most of the above although it’s perhaps worth expanding a little. The single most important concept in DDD is to focus on the problem domain. To put technology obsession to the side and concentrate primarily on modelling the problem you’re trying to solve. So put ajax, ORMs, databases, frameworks etc. into the … Read more