domain-driven-design

问题 I'm using a DDD/CQRS/ES approach and I have some questions about modeling my aggregate(s) and queries. As an example consider the following scenario: A User can create a WorkItem, change its title and associate other users to it. A WorkItem has participants (associated users) and a participant can add Actions to a WorkItem. Participants can execute Actions. Let's just assume that Users are already created and I only need userIds. I have the following WorkItem commands: CreateWorkItem

问题 I am designing a WCF service using DDD. I have a domain service layer that calls repository to create domain objects. The repository is implemented using ADO.Net and not an ORM. The data comes from DB using Stored Procs. While creating an object say an Address the SP returns an id for state. The SP will not join address table with the state table. The state is represented by a value object class State that has id, abbr and name properties. The list of state objects can be cached (using system

问题 I am designing a WCF service using DDD. I have a domain service layer that calls repository to create domain objects. The repository is implemented using ADO.Net and not an ORM. The data comes from DB using Stored Procs. While creating an object say an Address the SP returns an id for state. The SP will not join address table with the state table. The state is represented by a value object class State that has id, abbr and name properties. The list of state objects can be cached (using system

来源： https://stackoverflow.com/questions/40660163/microservices-dependence-management-governance-or-domain-driven-design

来源： https://stackoverflow.com/questions/40660163/microservices-dependence-management-governance-or-domain-driven-design

来源： https://stackoverflow.com/questions/59712039/should-a-single-command-address-multiple-aggregates

来源： https://stackoverflow.com/questions/59712039/should-a-single-command-address-multiple-aggregates

问题 I realize that persistence frameworks such as Morphia and Hibernate rely on annotations on domain objects to do their magic. At some level, it seems to me that this is inserting persistence concerns into the domain layer which is something we're supposed to strive to avoid. Is this something that I should try to dodge by perhaps using an external configuration file or maybe separate DTOs from the domain model? Or is this little leak between the persistence and domain layers generally regarded

问题 I have a domain model Product with a list of Prices. public class Product { private List<int> _prices; //Note that this is a value object in my actual code public void AddPrice(int price) { var currentPrice = _prices.LastOrDefault(); if(price < currentPrice) _prices.add(price) } } When a price changes I want a bunch of things to happen. Using an anemic domain model this is quite easy because I can just keep this bit in my service: if(price < currentPrice) _prices.Add(price) And then tack on a

问题 I want to create an app by implementing DDD using Spring. Let's say I have a business entity Customer and an interface CustomerRepository. Since spring provides CrudRepository and JpaRepository to perform basic CRUD operations and other operations like finder methods by default I want to use them. So my interface becomes @Repository public interface CustomerRepository extends JpaRepository<Customer, Long>{ } But according to DDD, interfaces should be in domain layer and the implementation