The current database schema has two major problems:
* German column names**German column names** - This leads to confusion for non-German speaking developers, diminishing developer experience, making onboarding more involved and leading to subtle errors: `adresstyp` vs `address_type`, note the different amount of "d"
* Large Object (LOB) Columns (`data`) - This makes it hard to export and query existing data.
During this refactoring, these problems should be rectified, with the following constraints:
* The FundraisingFrontend, Fundraising Operation Center and Export (SpendenDumper) must be operational at all times.
* We want to get rid of FundraisingStore "library" in the fundraising-donation and fundraising-memberships code repositories to avoid forced updates.
* We want to keep our domain objects unaffected by database technology - no ORM annotations on them. Use a separate XML file instead
AC:
* All column names are in English
* The data stored in the LOB is split out into tables
* All database access is behind one or more interfaces, using the [[ https://martinfowler.com/eaaCatalog/repository.html | Repository Pattern ]]
Note:
* To keep the applicFundraising Operationn Center and export working we could store the data in several places inithout huge refactorings, we could store the database redundantly, using the [[ https://www.martinfowler.com/bliki/StranglerApplication.html | StranglerApplication ]] pattern: wrap the current repository in a new repository,
1) Copy the `DoctrineDonationRepository` and `DoctrineMembershipApplicationRepository` to the FundraisingFrontend, change the `Doctrine` prefix to `Legacy`
2) Change the `DoctrineDonationRepository` in `fundraising-donation` and `fundraising-membership` to map the Domain entities to database tables.
3) In FundraisingFrontend, create `DonationRepositoryWrapper` and `MembershipApplicationRepositoryWrapper` classes that implement the repository interfaces and take 2 the Legacy and newly created repositories. and during the refactoring phase store the data both through the old repository and in new tables.Whenever an interface method is called, both repositories must receive the method call.
Possible tables/objects (to be discussed)
* donation
* donor
* payment (we'll have to see how we model the different payment types & their metadata)
* comment
* tracking (impcount, keyword and campaign from banner)
* buckets (bucket and name campaign from banner)
* membership_applications
* membership_applicants
* subscriptions (we can probably drop the address part because we use the subscription feature only for collecting emails for various purposes)
Maybe not every Domain object needs a table, minor objects (like `DonorName`) could be implemented as [[ https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/cookbook/custom-mapping-types.html | Mapping Types ]].
Resources:
* https://www.martinfowler.com/articles/evodb.html
* https://martinfowler.com/eaaCatalog/repository.html