AuditLogMessagingService

Responsible for construction and sending of messages into audit log.

CustomerReferralCodeGeneratorService

Responsible for generation referral code.

Generated code have length based on value in ReferralConfiguration and it is unique. Uniqueness is ensured by looking into database and generating it again in case it already exists. After specified number of retries defined in same config warning is logged.

CustomerReferralCodeService

Responsible for management of referral codes of all customers. Uses CustomerReferralCodeGeneratorService for generation and performs all necessary side effects.

Validation is checking if given code exists in the database thus it is safe to change configuration or whole strategy of generation of the code.

MessagingService

Responsible for sending events and snapshots.

Note: I would consider refactoring Snapshot parts into places where it is used and leave only sendReferralInformationChangedEvent method there. Reason is that having snapshots here hides where they are actually created. In case of sendReferralInformationChangedEvent (which updates FE) having it in a separate class is useful because when part of the information changes we still need to send whole “snapshot”.

NotificationService

Responsible for sending “Refer Friends” notification. Together with the attached classes implements Outbox pattern. See sequence diagram for more information.

OnboardEventsProcessorService

Responsible for performing most of the business logic in this domain, namely:

• new customer that used referral code on-boards

• customer paid his/hers first subscription and thus

  • is eligible for referral (code is generated)

  • if he/she used referral code, his/her referee should be rewarded

• recording of received rewards

Along with Listeners for given events, we provide development endpoints for simulation of this events in DevelopmentController.

OutputService

Wrapper for output-manager messages.

Note: I would consider moving methods to services that use them as private methods. Can cause troubles later

PostingService

Wrapper for sending reward postings into the Vault.

Note: Should be replaced by producer from the Postings library when it will be available.

ReferralCodeUsageService

Responsible for recording of customers that used referral code during on-boarding and tracks their progress (on-boarded / paid subscription / reward paid). Also provides list of people that given customer referred.

ReferralInformationService

Responsible for generation of views on whole referrals for particular customer. Combines information provided by other services - directly from ReferralCodeUsageService, via database data from CustomerReferralCodeService and RewardService

Note: It might be good idea to remove dependency from the database and use mentioned services. This is non-trivial because direct inclusion of mentioned services would cause circular dependency.

RewardService

Responsible for management of rewards for both referred customer and one who referred him/her. That means it specifies amount send (based on configuration) and tracks its claiming (not possible to claim / ready to claim / already claimed)

TransactionHistoryService

Wrapper responsible for sending of event into transaction-history-manager when reward is claimed. Based on TM payment integration, option B.

ReferralAuthorizationService

Responsible of authorization of controller endpoints with codeUsageId as input.

Note: Might be nice to use it only in those controllers that actually need it.