Domain driven design DDD：在哪一层生成通知消息？
假设我有一个系统，当有人邀请用户参加会议时，会向用户发送通知。在本例中，我想发送一个推送通知，显示消息“某人刚刚邀请您参加会议！”以及一些元数据，如会议ID 我认为我们大多数人都同意，发送此通知的逻辑应该在应用程序服务层内执行（与域服务或域本身相反） 但我的问题是，哪一层决定了实际发送的消息 假设在执行其业务逻辑后，域层发出一个带有相应“MeetingID”的“UserInvested”事件 然后，应用层在同步调用通知接口之前捕获事件。在什么时候显示信息“某人刚刚邀请你参加会议！”被添加 备选案文1：Domain driven design DDD：在哪一层生成通知消息？,domain-driven-design,Domain Driven Design,假设我有一个系统，当有人邀请用户参加会议时，会向用户发送通知。在本例中，我想发送一个推送通知，显示消息“某人刚刚邀请您参加会议！”以及一些元数据，如会议ID 我认为我们大多数人都同意，发送此通知的逻辑应该在应用程序服务层内执行（与域服务或域本身相反） 但我的问题是，哪一层决定了实际发送的消息 假设在执行其业务逻辑后，域层发出一个带有相应“MeetingID”的“UserInvested”事件 然后，应用层在同步调用通知接口之前捕获事件。在什么时候显示信息“某人刚刚邀请你参加会议！”被添加 备选案
消息在域内生成并附加到事件。但这似乎不太正确，因为域不应该知道或关心UI。通知与业务逻辑无关 备选案文2： 消息是在服务层生成的。域实体返回一个“userinvested”事件，然后服务层将该事件转换为消息对象，然后将消息对象传递给通知接口。根据事件类型，消息采用各种不同类型的消息进行硬编码。例如，“UserUninvited”会有一条“youhaveuninvited”消息，等等 这似乎是最简单的方法，但也似乎是一个黑客。服务层应该只为域提供一个执行环境，仅此而已。它不应该包含关于UI等的逻辑 备选案文3： 在通知接口本身的实现中硬编码消息。服务层只需通过通知接口传递原始域事件，通知接口负责根据事件类型生成适当的消息 这似乎并不理想，因为通知服务只是一个基础架构抽象。它不应该关心发送什么消息，而应该关心如何发送 我是否错过了更多的选择？关于在何处生成和附加通知消息，有什么见解吗 #2似乎是决定发送通知的正确地点。但这并不意味着它必须决定消息的实际内容和细节
您可以将其委托给与通知库对话的适配器。适配器是您的世界和任何通知技术世界之间的桥梁。它仍然可以使用应用程序中普遍存在的语言的方法，例如
SendInvitationNotification（）SendRejectionNotification（）GetInvitedUsers（）GetTodaysMeetings（）