Currently, the FundraisingStore is a common dependency across all bounded contexts. Updating the store means updating all bounded contexts, since composer does not allow different dependencies across sub-dependencies.
The situation is made worse by the database design in FundraisingStore, where we use the relations and the "cascade" feature to automatically create AddressChange entities when we save Donation and Membership entities. This makes the Donation and Membership domain unnecessarily depend on the AddressChange domain, which should be standalone.
To make each bounded context truly independent and maintainable on its own, I propose the following changes (in order):
- Invert the Donation->AddressChange and Membership->AddressChange relations:
- Add the table `AddressChangeAssociation` entity with the fields `entityType ENUM('Donation', 'Membership')` and `entityId`. Create a new Doctrine Migration file for that. The migration should also convert the existing AddressChange records.
- Remove automatic Address change generation from donation and membership repositories. Instead, modify the FunFunFactory to add a [[ https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/events.html#listening-and-subscribing-to-lifecycle-events | Doctrine event listener for the `postPersist` event of the Doctrine Entities `Donation` and `Membership` ]] that inserts AddressChange and AddressChangeAssociation entity.
- Clean up the address change route E2E tests in FundraisingFrontend
- Adapt the queries in the `ExportQueryBuilder` classes in the FOC.
- Move the Doctrine entities from FundraisingStore into the respective bounded contexts (Choosing a proper namespace, e.g. `DataAccess\DoctrineEntities`). Change the entity namespace in the bounded contexts from `WMDE/Fundraising\Entities` to the Domain-specific namespace, e.g. `WMDE\Fundraising\Donation\DataAccess\DoctrineEntities`.
- Remove FundraisingStore from the Fundraising Operation Center:
- Change the namespace references, similar to the changes in the previous step.
- Remove depenedcy from composer.json
- Each bounded context should have their own migration that gets picked up by FundraisingFrontend and FOC, which can have additional migrations. As part of this task, we'll delete existing migrations, as their changes are already in the production database. This will get rid of outdated dependencies, caused by using migrations version 1.8.