The payment classes suffer from the Anemic Domain Model problem - they are mostly value objects with no own behavior, with (de)serialization duplicated across donation and membership. Static analysis with PHPStan also highlights the problems (e.g. violations of the Liskov Substitution Principle.
Acceptance criteria:
- Payment-related code from donation and membership domains is moved to the payment domain. Domain Events (use cases) include
- Creating a payment
- Receiving a payment notification from an external payment provider (Paypal and Micropayment), changing the payment state. These can be different use cases, as the business logic for both is quite different.
- Canceling a payment. This is part of the "cancel donation" route and should only be possible for Direct Debit and Bank Transfer, other payments must be canceled via interaction with Fun OPs and that cancellation is not reflected in our database.
- Payment Entities are stored in their own database tables. This includes having a PaymentRepository interface and an implementation and following the suggestions and constraints in T203679: Refactor fundraising database schema. The tasks for these changes can be broken down further. For backwards compatibility (with the FOC and the export scripts), the DonationRepository and MembershipRepository must still write the payment data into the donation/membership record tables. When reading records, the repositories should use the new PaymentRepository,
- (Optional): Change donation export script and/or paypal export script to use the new tables.
Notes:
- We have collected some refactoring ideas in this document: https://github.com/wmde/FundraisingFrontend/blob/master/doc/Planning_for_Payment_refactoring.md