避免抽象类和继承

Question

考虑我正在使用邀请进行事件（每个“受邀人”代表邀请，因此多个邀请 em>用于单个事件）：

[«aggregate root»;Invitation]<>1..*-[«value object»;EventIdentifier]
[«value object»;EventIdentifier]-<>[«aggregate root»;Event]
[«value object»;Invitee|emailAddress;facebookIdentifier]-<>[«aggregate root»;Invitation]

然而，受邀者可以 电子邮件地址或一个facebookIdentifier，这就是业务逻辑的本质。 通常我会用FacebookInvitee和EmailInvitee创建一个AbstractInvitee，并创建一个与摘要的关联，但这是我现在所知道的邪恶。

相反，我应该实际上 FacebookInvitee 和 EmailInvitee ，邀请分别为facebookInvitee和{{1属性;如有必要，服务约会将它们合并在一起？

感谢您的建议！

修改

我刚刚提出了一个看起来很整洁的想法，

emailInvitee

[«value object»;Invitee|type;identifier]-<>[«aggregate root»;Invitation] 在某种程度上是type和FACEBOOK的常量，EMAIL则分别是FB UID或电子邮件地址。

Answer 1

  

通常我会使用FacebookInvitee和一个AbstractInvitee   EmailInvitee，并创建了与摘要的关联，但那是   我现在知道的邪恶。

继承不是那么邪恶。

如果您的班级FacebookInvitee和EmailInvitee具有相同的界面，我认为没有理由避免继承。如果接口不同并且需要转换为具体类型，则继承会增加复杂性。

  

type在某种程度上是FACEBOOK和EMAIL的常量   identifier然后分别是FB UID或电子邮件地址。

您的示例与Replace Subclass with Fields重构非常相似。无论如何，需要编写if-else代码块来检查被邀请者type并使用其identifier在某处发送邀请。谁应该对此负责？在您的解决方案中，Invitee只是一个没有行为的DTO。如果Invitee有行为且可以Send()邀请，那么我会使用继承并为每个具体类实现Send()（例如FacebookInvitee，EmailInvitee）。

Answer 2

我仍然保留一个抽象的Invitee值对象，其中包含2个衍生EmailInvitee和FacebookInvitee。

每种类型的受邀者都可以提升自己的WasNotified Domain Event风格，然后由知道如何处理它的基础设施层通知服务捕获。

Answer 3

我喜欢你的想法。

您可以在域层中放置NotificationService，并在基础架构层中添加适配器（FacebookNotificationService / EmailNotificationService）。

NotificationDispatcher（它也是一个适配器但聚合其他适配器）将通知（按被邀请者类型）分派给相应的适配器。