eli*_*st3 5 domain-driven-design
假设我有一个系统，当有人邀请用户参加会议时，用户会收到通知。在本例中，我想发送一条推送通知，显示消息“有人刚刚邀请您参加会议！” 以及一些元数据，例如会议 ID。
我认为我们大多数人都同意分派此通知的逻辑应该在应用程序服务层内执行（而不是域服务或域本身）。
但我的问题是，哪一层决定了发送的实际消息？
假设执行其业务逻辑后，域层发出带有相应“MeetingID”的“UserInvited”事件。
然后应用层捕获该事件，然后同步调用通知接口。在什么时候应该显示消息“有人刚刚邀请您参加会议！” 被添加？
选项1：
该消息在域内生成并附加到事件。但这似乎不太正确，因为域不应该知道或关心 UI。通知与业务逻辑无关。
选项2：
消息在服务层生成。域实体返回“UserInvited”事件，然后服务层将其转换为 Message 对象，然后将其传递到通知接口。根据事件类型，消息被硬编码为各种不同类型的消息。例如，“UserUninvited”将显示“您未被邀请”消息等。
这似乎是最简单的方法，但也似乎是一种黑客行为。服务层应该只是为领域提供一个执行环境，仅此而已。它不应该有关于 UI 等的逻辑。
选项 3：
在通知接口本身的实现中对消息进行硬编码。服务层仅通过通知接口传递原始域事件，通知接口负责根据事件类型生成适当的消息。
这看起来并不理想，因为通知服务只是一个基础设施抽象。它不应该关心发送什么消息，而只关心如何发送消息。
我缺少更多选择吗？关于在哪里生成和附加通知消息有什么见解吗？
#2 似乎是做出发送通知决定的正确位置。但这并不意味着它必须决定消息的实际内容和细节。
您可以将其委托给与通知库通信的适配器。适配器是您的世界与任何通知技术的世界之间的桥梁。它仍然可以具有使用应用程序通用语言的方法，例如等SendInvitationNotification()，这与存储库或读取模型外观可以公开或SendRejectionNotification()的方式非常相似。GetInvitedUsers()GetTodaysMeetings()