domain-driven-design

问题 Consider the following class. It tries to protect the access to the _assignedTrays . Actually, it works perfectly, since EF automatically links the backing field _assignedTrays to the property AssignedTrays - by convention (msdn) public class Rack { private List<Tray> _assignedTrays = new List<Tray>(); private Rack() { } public Rack(string rackId) { this.Id = rackId; } public string Id { get; private set; } public IReadOnlyList<Tray> AssignedTrays => this._assignedTrays.AsReadOnly(); public

问题 Consider the following class. It tries to protect the access to the _assignedTrays . Actually, it works perfectly, since EF automatically links the backing field _assignedTrays to the property AssignedTrays - by convention (msdn) public class Rack { private List<Tray> _assignedTrays = new List<Tray>(); private Rack() { } public Rack(string rackId) { this.Id = rackId; } public string Id { get; private set; } public IReadOnlyList<Tray> AssignedTrays => this._assignedTrays.AsReadOnly(); public

问题 I've been learning DDD for the past few days and struggling to understand some core concepts of aggregate roots. Maybe somebody could give me push in the right direction and elaborate what's best practice in this scenario: To make this example less complex, let's say we have a domain of two entities: restaurant and opening time. Restaurant is defined as aggregate root. From what I understood in all the online examples (correct me if I'm mistaken), the aggregate root is eager loading all sub

问题 I'm using DDD. I have the following interfaces: interface ICustomerRepository { void Disable(int customerId); } interface ICustomerService { void Disable(int customerId); } The application will work on a WebService. I wonder, should I use id's as parameter or the entire Customer entity? What are the pros and cons of each approach? 回答1: Well, the fact is that this behavior shouldn't be on the repository. Behavior should be placed in entities. However, your application service contract should

问题 I'm using DDD. I have the following interfaces: interface ICustomerRepository { void Disable(int customerId); } interface ICustomerService { void Disable(int customerId); } The application will work on a WebService. I wonder, should I use id's as parameter or the entire Customer entity? What are the pros and cons of each approach? 回答1: Well, the fact is that this behavior shouldn't be on the repository. Behavior should be placed in entities. However, your application service contract should

问题 [ Follow up from this question & comments: Should entity have methods and if so how to prevent them from being called outside aggregate ] As the title says: i am not clear about what is the actual/precise purpose of entity as a child in aggregate? According to what i've read on many places, these are the properties of entity that is a child of aggregate: It has identity local to aggregate It cannot be accessed directly but through aggregate root only It should have methods It should not be

问题 [ Follow up from this question & comments: Should entity have methods and if so how to prevent them from being called outside aggregate ] As the title says: i am not clear about what is the actual/precise purpose of entity as a child in aggregate? According to what i've read on many places, these are the properties of entity that is a child of aggregate: It has identity local to aggregate It cannot be accessed directly but through aggregate root only It should have methods It should not be

问题 [ Follow up from this question & comments: Should entity have methods and if so how to prevent them from being called outside aggregate ] As the title says: i am not clear about what is the actual/precise purpose of entity as a child in aggregate? According to what i've read on many places, these are the properties of entity that is a child of aggregate: It has identity local to aggregate It cannot be accessed directly but through aggregate root only It should have methods It should not be

问题 I have seen DDD Domain implementations where entities rely on the primary key ID when building Equals/GetHashCode methods. I understand why it is a good idea, as the primary key might be the only member which is not mutable. But there might also be situations where it is no good idea, though. Think about a Dictionary, holding entities which where just instantiated. The primary key (assume it is an auto-incrementing value, not a "business-related" value) is not assigned yet, it might be 0 on

问题 I have a UserEntity that is eventually persisted in the DB according to it's id property. In this case, the id property is obviously sensitive, because changing it would cause the UserEntity to be saved over a different UserEntity when persisted later. I would therefore like to help safe guard against something like this happening... Option 1. Do I FORCE the id to be passed into the constructor, thereby removing the Setter? This would mean that every UserEntity that the Repository is given to