Currently, the FundraisingStore is a common dependency across all bounded contexts. When changing the database schema in a backwards-incompatible way, we increase the major version number, This means updating all bounded contexts, even when only one bounded context is affected, 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):

PART I - Reverse AddressChange relation

• 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.
• Apply the migrations to the test and production database and update the code accordingly.

Part II - Move FundraisingStore code into bounded contexts

• 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.
• Each bounded context should have a factory class that can
  • create an entity manager (for the unit tests of the bounded context)
  • Return information about its mapping driver class (e.g. Doctrine\ORM\Mapping\Driver\AnnotationDriver or Doctrine\ORM\Mapping\Driver\XmlDriver) with a getDriverName and have a addPaths method that adds the entity-specific paths to the drivers.
  • return
• Add EntityManagerFactory to FundraisingFrontend:
  • initialize the Annotation and XML drivers and then call the addPaths method of the bounded contexts to add paths
  • Collect events from bounded contexts
• Remove FundraisingStore from the Fundraising Operation Center:
  • • Change the namespace references, similar to the changes in the previous step.
  • Copy EntityManagerFactory from FundraisingFrontend and add Backend-Specific entity paths (Users, Impressions) to the annotation driver.
• Remove the FundraisingStore dependency from all composer.json files