Healthy Benefits¶

This component is responsible for everything related to healthy benefits. This includes benefits subscription configuration (which relies on the contracting MoMo for subscription versions management) and healthy benefits affiliation.

This component is not responsible for managing payments.

The component aims to be global and used by all countries.

public layer provides the public API of the component. It's the only layer that should be used by other components to deal with contracting.
external layer provides an abstraction layer that makes possible to use it for different countries (in other words, healthy_benefits interacts with the outside world through this layer)

Subcomponents¶

As this component's scope is large, we are trying to split it into smaller subcomponents to make it easier to maintain and uncouple responsibilities.

The most important subcomponents are:

affiliation: responsible for the healhty benefits enrollments.
subscription: responsible for the healthy benefits subscription configuration (its lifecycle is handled by contracting)

Technical architecture¶

Here ⧉ the documentation about the modular monolith.

👩‍👩‍👦 Subcomponents¶

The Healthy Benefits component follows the Modular Monolith Subcomponents guideline ⧉. The following subcomponents are defined:

Affiliation¶

This submodule is responsible to handle healthy benefits enrollments.

It links one external ref profile_ref (for example for Spain, this is the ID of the healthy_benefits_profile, but you can put whatever you need here) and one benefit_type_ref (a week reference to the benefit the member is enrolled to. For example for Spain, this is the type of the benefit, ie food, transport or nursery), for one subscription_ref (a weak reference to a subscription, that should come from the subscription submodule)

It offers several public method to create, update, cancel or retrieve those enrollments.

For Spain, a member will have one enrollment per subscribed benefit.

Subscription¶

This submodule is responsible for the healthy benefits subscription configuration.

It is NOT responsible for the subscription lifecycle management, which is only handled by the contracting component.

It stores:

the different populations that exist for healthy benefits
the different benefits configurations
the signed documents linked to the subscription
the subscription version configuration at a time
the payload is responsible for linking benefit configuration for a population (stored in benefits) and a subscription_version coming from contracting
refer to the contracting submodule to understand how subscription version lifecycle works

classDiagram
    Benefit <--> Population
    Benefit <--> Payload
    Payload <--> SignedBundle
    SignedDocument <--> SignedBundle
    Payload <..> SubscriptionVersion


    namespace Subscription {
        class Population
        class Payload{
            +Int price
        }
        class Benefit{
            +String type_ref
            +String profile_ref
            +uuid population_id
            +uuid payload_id
        }
        class SignedBundle
        class SignedDocument
    }
    namespace Contracting {
        class SubscriptionVersion
    }

Hold "Alt" / "Option" to enable pan & zoom

🔨 Typing¶

Everything should be typed

🌎 Public API¶

All public methods should be exposed through healthy_benefits/public module
We are caution when exposing a new method as it's a commitment to maintain it.
We should try to keep the public API as small as possible.
We try to make our APIs composable and flexible