DDD - 领域模型问题
我与合作伙伴讨论了这种情况：
**Publishers root entity
Advertiser root entity**
每个实体都共享共同信息： 电子邮件、账单地址、正常地址、性别、SSN 等
我已决定： 具有值对象地址和其余属性的人员实体。这样，如果我想访问有关某人的特定信息（电子邮件、性别、鸟的日期），我不必通过发布商或广告商根实体来获取它（将人视为聚合根）。
Sample: **Person.BillingAddress.Address1 :
Person.BillingAddress.Address2 :
Person.BillingAddress.POBOX :
Person.Email :
Person.Sex**
我的队友建议使用抽象类来实现，广告商和发布商继承自 Person 抽象类，以便拥有所有公共属性。
最好的方法是什么？如果您有，请指导我们。
谢谢， 佩德罗·德拉克鲁斯
I have i discussion with a partner we have this scenario:
**Publishers root entity
Advertiser root entity**
Each of those entities share common info :
Email, BillingAddress, NormalAddress, sex, SSN, etc.
I have decide:
Person Entity with a Value object Address and rest of properties. This way if i want to access a specific info about a Person (email, sex, dateofbird) i dont have to go through publisher or advertiser root entities to get it (treat Person as an aggregate root).
Sample: **Person.BillingAddress.Address1 :
Person.BillingAddress.Address2 :
Person.BillingAddress.POBOX :
Person.Email :
Person.Sex**
My teammate propose to to do it using abstract class, advertiser and publisher inherits from Person abstract class in order to have all common properties.
What is the best way to do it?. If you have one please guide us.
Thanks,
Pedro de la Cruz
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
我认为你是对的。当行为是常见的（某物是另一物的一种）时，继承才有意义，那么 Person 就不会仅仅因为属性相似而成为另一物。这不是代码重用。
I think that you are right. Inheritance just make sense when the behaviour is common (some thing is a kind of other thing), then Person isnt a kind of OTHER THING just because the properties are similars. It isnt code reuse.
您应该倾向于组合而不是继承。
您的设计更好，因为否则，如果在某个时候您需要在此层次结构中引入其他内容（例如，使您的根实体成为 AuditableEntity），您将无法这样做（除非您的语言支持多重继承 - 这很糟糕）。
You should favour composition over inheritance.
Your design is better because otherwise if at some point you need to introduce something else in this hierarchy (e.g make your root entities AuditableEntity) you won't be able to do so (unless your language supports multiple inheritance - which is bad).
在这种情况下，我不关心继承 - 我认为它很脆弱。
我更喜欢基于组合和角色的方法。管理员角色可以包装 Person 对象并具有与该角色关联的所有特殊属性和行为。
I don't care for inheritance in this case - I think it's brittle.
I would prefer an approach based on composition and Roles. An Administrator Role might wrap a Person object and have all the special attributes and behaviors associated with the Role.
我认为广告商和发布商应该继承自公司，并且公司应该拥有联系人（或您的情况下的人员）的集合。
从技术上讲，公司可以拥有多个分支机构。
那么每个分支机构可以有一个地址，每个联系人（人）可以有一个地址。
I would think Advertiser and Publisher should inherit from Company, and a Company should have a collection of Contacts (or Persons in your case).
Technically Company could have a collection of Branches.
Then each Branch can have an Address, and each Contact (Person) can have an Address.
@ Scott 从 person 继承有什么问题？
@Tim 继承在这里如何失败？
让 Person 为抽象类，Advertiser 和 Publisher 作为具体类。这样Advertiser将拥有共同的属性，对于Publisher来说也是如此，现在我们可以传递person。
广告商是人。
发布者是人。我更喜欢继承
@ Scott what is the problem in inheriting from person ?
@Tim how inheritance fails here ?
Let Person be abstract class and Advertiser and Publisher as concrete class. In this way Advertiser will have common properties, same for publisher, now we can pass person.
Advertiser is Person.
Publisher is Person. I prefer inheritance
我的 2 美分...
当我阅读你的问题时，似乎自然人不是你模型的一部分。您的模型涉及出版商和广告商。
首先。我认为自然人（或公司）必须生活在一个单独的“层参考”域中，该域可以转变为“层或合作伙伴存储库”。
第二。由于您的模型需要发布商和广告商，我认为 DAL（以及存储库，但以较小的方式）应该负责定义和创建这些实体。 DAL 是您应该拥有自然人项目的唯一位置（因为它不是模型中的实体，我将其称为“项目”），并且您应该注意将其与模型隔离。正如发布者和合作伙伴实体的建设计划所暗示的那样，自然人必须留在数据方面。精炼和水合这些实体应该在存储库中。
我认为你的模型中不应该有一个“Person”类，我认为你应该将它放在存储库“下方”，从你的模型中不可见。
My 2 cents...
As I am reading your question, it seems the physical person is not a part of your model. Your model deals with Publishers and Advertisers.
First. I think the physical person (or company) has to live in a separated "Tier Referential" domain, that can transform into a "Tier or Partner Repository".
Second. As your model needs Publishers and Advertisers, I think it should be the responsibility of the DAL (and the repository but in a smaller manner), to define and create these entities. The DAL is the only place you should have the physical person item (as it is not an entity in your model, I called it "item"), and you should take care of isolating it from the model. The physical person has to stay on the data-side, as it is implied in the construction plan of the Publishers and the Partners entities. Refining and hydrating those entities should be in the repository.
I think you should not have a "Person" class in your model, I think you should have it "beneath" the repository, invisible from your model.
（警告 - 过于简单化）
在这种情况下，继承无法通过“is a”测试。
通常您会问“is”我的类“a”
(warning - overly simplistic)
Inheritance in this case fails the "is a" test..
normally you would ask "is" my class "a"
<whatever>or does it "have" a<whatever>好吧，我知道已经过去很多年了，我来不及在这里回答了。
几年前，DDD 这个词几乎没有什么区别，但在微服务时代，DDD 的重要性突然上升。因此，对于所有微服务爱好者来说，这个问题会造成很多困惑。
Well I know its been years and i am too late to answer here.
Few years back putting the word DDD would hardly make any difference, but in microservices era the importance of DDD has suddenly risen. So to all the Microservices enthusiasts this question would create a Lot of Confusion.