Change Details

While looking at the codebase and running PHPStan with increased analysis level, some problems with the code were found. The payment domain can be decoupled more from donation and memberships and can gain some expressiveness to become a real subdomain instead of a bunch of value objects. Collection of the pain points and refactoring ideas: https://github.com/wmde/FundraisingFrontend/blob/payment-refactoring-planning/doc/Planning_for_Payment_refactoring.md

The payment classes suffer from the [[ https://martinfowler.com/bliki/AnemicDomainModel.html | 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 [[ https://en.wikipedia.org/wiki/Liskov_substitution_principle | 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}. 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/payment-refactoring-planning/doc/Planning_for_Payment_refactoring.md

While looking at the codebase and running PHPStan with increased analysis level,The payment classes suffer from the [[ https://martinfowler.com/bliki/AnemicDomainModel.html | 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 [[ https://en.wikipedia.org/wiki/Liskov_substitution_principle | 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}. 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. some problems with the code were found.When reading records, The payment domain can be decoupled more from donation and memberships and can gain some expressiveness to become a real subdomain instead of a bunch of value objects. Collection of the pain points and refactoring ideasthe 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/payment-refactoring-planning/doc/Planning_for_Payment_refactoring.md