Change Details

From a Domain perspective, the `TrackingInfo` class is not necessarily a part of `Donation` and the `AddDonation` use case, since tracking is not necessary for some domain aspects (payment, changing donation state) and can be seen as standalone for other domains (analytics). Also, the tracking information can be reused for memberships. Acceptance criteria: * Tracking is its own bounded context while keeping compatibility with legacy donation database. * Fields `source`, `color` and `layout` are removed - they are superseded by the matomo tracking codes and the bucket testing log and are not exported since 2019. Implementation hints: * Remove `TrackingInfo` from `Donation` in donation bounded context. Remove code form repository, tests, request etc * Create new "Tracking" bounded context with "TrackDonation" use case, containing the removed code from previous step. Tracking info should be stored in its own table, the code for modifying the legacy donation table should live in FundraisingFrintend * Assuming {203679} is still ongoing: In FundraisingFrontend: Create a that write the tracking information into the legacy donation table (unding the `data` attribute). * In FundraisingFrontend: Create domain event handler for `DonationCreated` that calls the `TrackDonation` use case and the legacy tracking writer service.

We have several deprecated fields in the `TrackingInfo` class, that should be removed from the class and the `DoctrineDonationRepository` implementation. To Discuss: * Are we still using the banner counts stored in donation? * From a Domain perspective, the `TrackingInfo` class is not necessarily a part of `Donation` and the `AddDonation` use case, since tracking is not necessary for some domain aspects (payment, changing donation state) and can be seen as standalone for other domains (analytics). Also, the tracking information can be reused for memberships and subscriptions, giving us a clearer picture where our members and subscribers are coming from. However, having a separate new bounded context might be overkill for storing 3 distinct values (banner impression counts and matomo tracking code) that are needed for donations only at the moment. Acceptance criteria: * Fields `source`, `color` and `layout` are removed - they are superseded by the matomo tracking codes and the bucket testing log and are not exported since 2019. Implementation hints if we decide to create a new bounded context: * Remove `TrackingInfo` from `Donation` in donation bounded context. Remove code form repository, tests, request etc * Create new "Tracking" bounded context with "TrackDonation" use case, containing the removed code from previous step. Tracking info should be stored in its own table, the code for modifying the legacy donation table should live in FundraisingFrontend * Assuming {T203679} is still ongoing: In FundraisingFrontend: Create a " legacy tracking writer service" that writes the tracking information into the legacy donation table (using the `data` attribute). * In FundraisingFrontend: Create domain event handler for `DonationCreated` that calls the `TrackDonation` use case and the legacy tracking writer service.

From a Domain perspective, the `TrackingInfo` class is not necessarily a part of `Donation` and the `AddDonation` use case, since tracking is not necessary for some domain aspects (payment, changing donation state) and can be seen as standalone for other domains (analytics). AlsoWe have several deprecated fields in the `TrackingInfo` class, the tracking information can be reused for membershipsthat should be removed from the class and the `DoctrineDonationRepository` implementation. Acceptance criteria:To Discuss: * Tracking is its own bounded context while keeping compatibility with legacy donation database.Are we still using the banner counts stored in donation? * From a Domain perspective, the `TrackingInfo` class is not necessarily a part of `Donation` and the `AddDonation` use case, since tracking is not necessary for some domain aspects (payment, changing donation state) and can be seen as standalone for other domains (analytics). Also, the tracking information can be reused for memberships and subscriptions, giving us a clearer picture where our members and subscribers are coming from. However, having a separate new bounded context might be overkill for storing 3 distinct values (banner impression counts and matomo tracking code) that are needed for donations only at the moment. Acceptance criteria: * Fields `source`, `color` and `layout` are removed - they are superseded by the matomo tracking codes and the bucket testing log and are not exported since 2019. Implementation hints if we decide to create a new bounded context: * Remove `TrackingInfo` from `Donation` in donation bounded context. Remove code form repository, tests, request etc * Create new "Tracking" bounded context with "TrackDonation" use case, containing the removed code from previous step. Tracking info should be stored in its own table, the code for modifying the legacy donation table should live in FundraisingFriontend * Assuming {T203679} is still ongoing: In FundraisingFrontend: Create a " legacy tracking writer service" that writes the tracking information into the legacy donation table (undusing the `data` attribute). * In FundraisingFrontend: Create domain event handler for `DonationCreated` that calls the `TrackDonation` use case and the legacy tracking writer service.