DDD架构疑问：会议邀请通知消息应在哪一层生成？

Great question—this is one of those nuanced layer boundary calls that trips up a lot of folks, even experienced devs. Since you already have the notification scheduling locked in the application service layer, let’s break down the message generation decision based on what the message depends on:

1. If the message relies on domain rules or state → Put it in the Domain Layer #

If your notification text needs to reflect core business logic or domain-specific formatting (e.g., how meeting IDs are displayed, whether certain meeting details are included based on domain rules), this logic belongs in the domain layer—either directly on an entity or in a domain service.

Why? Because tying message generation to the domain ensures that if your business rules change (say, you start requiring meeting IDs to be prefixed with a team code), the notification automatically updates without having to modify application layer code. It keeps your domain logic cohesive and avoids duplication.

Example (Java-like pseudocode):

// Domain Layer: Meeting Entity
public class Meeting {
    private String meetingId;
    private MeetingType type;
    private LocalDateTime startTime;

    // ... constructor, getters, domain methods

    public String generateInvitationNotificationText() {
        // Domain-specific logic: only include start time for scheduled meetings
        String detail = type == MeetingType.SCHEDULED 
            ? String.format(" (starts at %s)", startTime.format(DateTimeFormatter.ISO_LOCAL_DATE_TIME))
            : "";

        return String.format("Someone just invited you to a meeting! Meeting ID: %s%s", meetingId, detail);
    }
}

Your application service would then call this method, grab the metadata (like the raw meeting ID) from the domain entity, and pass both to the notification dispatcher.

2. If the message is purely presentation/dispatch-focused → Keep it in the Application Service Layer #

If your notification is a static string with just attached metadata (no domain-specific formatting or rules), you can safely generate the message directly in the application service. This is common when the message is a simple alert that doesn’t need to adapt to domain state changes.

You can even extract it into a small helper class (like NotificationMessageFactory) within the application layer if you want to keep your service methods clean.

Example:

// Application Service Layer
public class MeetingInvitationService {
    private final NotificationDispatcher notificationDispatcher;

    public void sendInvitationAlert(User invitee, Meeting meeting) {
        String message = "Someone just invited you to a meeting!";
        Map<String, Object> metadata = Map.of(
            "meetingId", meeting.getMeetingId(),
            "organizerId", meeting.getOrganizer().getId()
        );

        notificationDispatcher.sendNotification(invitee, message, metadata);
    }
}

3. If you need templating/multilingual support → Use an Infrastructure Layer Helper #

If your notifications require template rendering, multiple languages, or integration with external messaging tools (like email template services), you can delegate message generation to an infrastructure layer component. The application service would fetch the necessary domain data, pass it to the infrastructure template service, and then dispatch the generated message.

This keeps your domain and application layers free from presentation-specific concerns like template syntax or language localization.

Key Takeaway #

The golden rule is: keep message generation logic close to the rules or data it depends on. If it’s tied to domain state/rules, domain layer wins. If it’s just a static alert for dispatch, application layer is fine. For external presentation needs, lean on infrastructure.

内容的提问来源于stack exchange，提问作者elimist3