You say: Something of a compromise between the two concepts would be to implement some kind of DSL as a templating language. I’m not even sure that this would be successful however, as all of the content creators, with one exception, are completely non technical. Honestly, this sounds like exactly the approach I would use. … Read more
I have read many articles about the REST on the internet. Based on what I see here, you really need to watch at least one of Jim Webber’s talks on REST and DDD Rest in Practice Domain Driven Design for RESTful Systems But what to do with the rest of the use cases? Ignore the … Read more
Define the DTO to the layer where the source of the values comes from. Relative to OP’s question: place the DTO in the Application Service Layer. DTO is an output of that layer, it makes sense if you define it there. Don’t put your DTO in the Domain Layer. The Domain Layer does not care … Read more
It’s ok to store Value Objects in a separate table, for the very reasons you’ve described. However, I think you’re misunderstanding Entities vs VOs – it’s not a persistence related concern. Here’s an example: Assume that a Company and Person both have the same mail Address. Which of these statements do consider valid? “If I … Read more
If you validate the username using the read model before you send the command, we are talking about a race condition window of a couple of hundred milliseconds where a real race condition can happen, which in my system is not handled. It is just too unlikely to happen compared to the cost of dealing … Read more
A subdomain is a part of your business. There are core domains, supporting domains and generic domains. Core domains are where the money is, supporting domains support your core business, and generic domains are the ones you need, but don’t care a lot about, so you would probably buy them of the shelf. For an … Read more
Reduced to the essential distinction, identity matters for entities, but does not matter for value objects. For example, someone’s Name is a value object. A Customer entity might be composed of a customer Name (value object), List<Order> OrderHistory (List of entities), and perhaps a default Address (typically a value object). The Customer Entity would have … Read more
EDIT: As this seem to be a top result on Google and my answer below is not, please refer to this much better answer: https://stackoverflow.com/a/1222488/1240557 OLD ANSWER (not so complete :)) In order to create good software, you have to know what that software is all about. You cannot create a banking software system unless … Read more
Firstly, if you don’t know that you need it then it’s possible that you don’t need it. If you don’t recognize the problems that DDD solves then maybe you don’t have those problems. Even DDD advocates will frequently point out that DDD is only intended for large (>6 month) projects. Assuming that you’re still reading … Read more
The difficulty with DDD samples is that they’re often very domain specific and the technical implementation of the resulting system doesn’t always show the design decisions and transitions that were made in modelling the domain, which is really at the core of DDD. DDD is much more about the process than it is the code. … Read more