Reducing Duplication in Email Notification Settings with an Abstract Service in Spring Boot - Finovara

When working on user notification settings in my Spring Boot project, I noticed a lot of duplicated logic across different email notification services

Each type of notification (password change, etc.) was doing almost the same thing:

• loading the user
• reading notification settings
• updating a boolean flag
• sending an email conditionally
• logging activity

So I decided to refactor it using an abstract base service.

Before refactor (problem)

Every service contained similar logic like this:

User user = userManagerService.getUserByEmailOrThrow(email);
NotificationEmailSettings settings = user.getNotificationEmailSettings();

settings.setNotifyOnPasswordChange(dto.enabled());

And then duplicated email sending + activity logic across multiple services.

This led to:

1. duplicated code
2. inconsistent behavior risk
3. harder onboarding for new notification type

Solution: AbstractNotificationEmailService

I introduced a template-based abstract service that handles the shared workflow.

Now the base class looks like this:

@RequiredArgsConstructor
public abstract class AbstractNotificationEmailService {

    protected final UserManagerService userManagerService;
    protected final NotificationEmailSender notificationEmailSender;

    @Transactional
    public void saveEmailNotification(String email, NotificationEmailDto dto) {
        User user = userManagerService.getUserByEmailOrThrow(email);
        NotificationEmailSettings settings = user.getNotificationEmailSettings();

        boolean enabled = isEnabled(dto);
        applySetting(settings, enabled);

        handleActivity(email, enabled);
    }

    public NotificationEmailDto getEmailNotification(String email) {
        User user = userManagerService.getUserByEmailOrThrow(email);
        NotificationEmailSettings settings = user.getNotificationEmailSettings();

        return mapToDto(settings);
    }

    public void sendEmail(User user) {
        notificationEmailSender.sendIfEnabled(
                user,
                this::isNotificationEmailSettingsEnabled,
                this::sendEmailToUser
        );
    }

    protected abstract boolean isEnabled(NotificationEmailDto dto);

    protected abstract void applySetting(NotificationEmailSettings settings, boolean value);

    protected abstract boolean isNotificationEmailSettingsEnabled(NotificationEmailSettings settings);

    protected abstract NotificationEmailDto mapToDto(NotificationEmailSettings settings);

    protected abstract void sendEmailToUser(User user);

    protected void handleActivity(String email, boolean enabled) {
        // optional override
    }
}

Example implementation

Each notification type now only defines its own behavior.

Example: password change notification

@Service
public class NotifyPasswordChangeService extends AbstractNotificationEmailService {

    private final PasswordChangeEmailService passwordChangeEmailService;
    private final SettingsActivityService settingsActivityService;

    public NotifyPasswordChangeService(
            UserManagerService userManagerService,
            NotificationEmailSender notificationEmailSender,
            PasswordChangeEmailService passwordChangeEmailService,
            SettingsActivityService settingsActivityService
    ) {
        super(userManagerService, notificationEmailSender);
        this.passwordChangeEmailService = passwordChangeEmailService;
        this.settingsActivityService = settingsActivityService;
    }

    @Override
    protected boolean isEnabled(NotificationEmailDto dto) {
        return dto.enabled();
    }

    @Override
    protected void applySetting(NotificationEmailSettings settings, boolean value) {
        settings.setNotifyOnPasswordChange(value);
    }

    @Override
    protected boolean isNotificationEmailSettingsEnabled(NotificationEmailSettings settings) {
        return settings.isNotifyOnPasswordChange();
    }

    @Override
    protected NotificationEmailDto mapToDto(NotificationEmailSettings settings) {
        return new NotificationEmailDto(settings.isNotifyOnPasswordChange());
    }

    @Override
    protected void sendEmailToUser(User user) {
        passwordChangeEmailService.sendEmail(user);
    }

    @Override
    protected void handleActivity(String email, boolean enabled) {
        settingsActivityService.createSettingActivity(
                email,
                enabled ? SettingActivityStatus.ENABLED : SettingActivityStatus.DISABLED,
                SettingType.NOTIFICATION_PASSWORD_CHANGED
        );
    }
}

What improved

After this refactor:

• Better structure: shared logic is in one place
• Less duplication: no repeated boilerplate across services
• Easier extension:new notification = just extend abstract class
• More consistency: same flow for every notification type

Thanks for reading, if you want check my github!

M4rc1nek / finovara-backend

Backend service for a personal finance management application

Finovara

Backend platform for a personal finance management application, built with Java 25 and Spring Boot 4 as a set of microservices.

About the Project

Finovara is a personal finance platform designed to help users take full control of their money. The backend exposes a secure REST API that powers tracking of income and expenses, budget management, savings goals, shared accounts and financial reporting.

The platform is built as a set of independent services, each responsible for a separate area of the domain, so that individual parts of the system can be developed, deployed and scaled on their own. Security is a central concern: authentication is based on JWT, sessions are tracked per device, and user activity is recorded in an audit log.

---

Key Features

Accounts and Security

• Authentication and Authorization - stateless JWT security built on Spring Security, with an access and refresh token flow.
• Device and Session Tracking…

View on GitHub

Comments

[BuildBaseKit]

This is such a clean use of abstraction

most people either copy paste this logic everywhere
or overcomplicate it with too many layers

template method here feels like the right balance

also like how adding a new notification is just
“extend + implement specifics”

makes scaling this way less painful later

[Marcin Parśniak]

thank you so much!