domain-driven-design

问题 As I understand, the Bounded Context can have modules, the modules can have many aggregate roots, the aggregate root can have entities. For the persistence, each aggregate root should have a repository. With the numerous aggregate roots in a large project, is it okay to use a Generic Repository , one for ready only and one for update? Or should have separate repository for each aggregate root which can provide better control. 回答1: In a large complex project, I wouldn't recommend using a

问题 I am upgrading a legacy database system into .NET + Entity Framework 6 (code-first POCO) + PostgreSQL. For ease of programming, I wish to split a large table (200+ fields) into multiple entities, eg.: Franchise FranchiseLegalEntity FranchiseBilling FranchiseSignup FranchiseAllocation FranchiseCompliance FranchiseMiscellaneous FranchiseNotifications I was delighted to find EF6 supports "table splitting": mapping a single table to multiple entities to split the fields up. However attempting to

问题 I am trying to model purchasing domain using CQRS & DDD, i know that i raise events in domain but i don't know where to Register them when i am using commands. Should event handlers be registered in command handlers? or maybe i misunderstood something. this is my process can you help model it right way? Finalize purchase order Command is given, than command handler finalizes order (gets order from repository, changes its state and saves back to db), order finalized event occurs in domain

问题 Are there any conventions or good practices when naming interfaces for EJBs? I am trying to apply some DDD principles in my application as well so I am using the "service" sterotype on the classes that is the interface for the world outside. If I have a QuestionService EJB that provides business logic operations to clients, what would the @Local/@Remote Interface be named? All the books I read so far only names them QuestionServiceLocal/QuestionServiceRemote. Is this suffcient (I am not

问题 I am having difficulty in attempting to ascertain which domain within a given model can be considered the "core domain". It can be tricky especially if there are several domains which are core to the function of a business. I would like someone to outline a systematic process to single out the core domain when dealing with a system that has multiple candidates. 回答1: Core domain - the most important subdomain, which is essential for the business. Without it the business would fail. If you ever

问题 In Domain-driven design if I want to use a repository I need to have an aggregate for it - as I understand. So I have a User, that has id, login, email, and password. A user is a domain Entity with unique Id. When i want to add a User to User repository, should I build first an Aggregate with only Aggregate Root that is my User entity and nothing more? It looks like a proxy to User in this case, unneeded layer. Or maybe I missed something here? Maybe User isnt an Entity, even if it looks like

问题 Let's consider the typical Order and OrderItem example. Assuming that OrderItem is part of the Order Aggregate, it an only be added via Order. So, to add a new OrderItem to an Order, we have to load the entire Aggregate via Repository, add a new item to the Order object and persist the entire Aggregate again. This seems to have a lot of overhead. What if our Order has 10 OrderItems ? This way, just to add a new OrderItem , not only do we have to read 10 OrderItems , but we should also re

问题 What's the best way to set default properties for new entities in DDD? Also, what's the best way to set default states for complex properties (eg. collections)? My feeling is that default values should be in the models themselves as they are a form of business rule ("by default, we want X's to be Y & Z"), and the domain represents the business. With this approach, maybe a static "GetNew()" method on the model itself would work: public class Person { public string Name { get; set; } public

问题 a) With BCs containing two or more subdomains there's a possibility of concepts overlapping and even worse, the same concept ( used by several of these subdomains ) may be interpreted/understood differently by each subdomain. Regardless, if BC does contain numerous subdomains, should it provide several Ubiquitous languages, one for each subdomain, or should all subdomains share the same Ubiquitous language? b) I assume when a single subdomain spans several BCs, each of these BCs should define

问题 Should value object hold reference to entity in DDD methodology? EDIT @Dmitry: This is probably my case. Here I attach class diagram where the Account hold references to collection of IInvoiceable items. I treat with Tenant as entity, but it owns only 1 account and i dont think that Account needs identity. its part of Tenant . Or should I treat it as Entity? To me it doesnt make sense. 回答1: Yes it can. This would be a relatively obscure case but DDD allows for it and it can be useful. From