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. 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.

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.

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.