Change Details

Additionally to our `PaymentMethod` classes we'd like to create a `Payment` class that takes over the payment-related of the fields and responsibilities of the `Donation` and `Membership` classes. Also, we would like to store payments and all the data associated with the payment method in separate database tables Acceptance Criteria - The domain objects are refactored according to the data model - There is a `PaymentRepository` interface with methods for getting a payment and storing a payment - There is an implementation of the interface that stores the data in normalized database tables Implementation details - Each payment method should have its own database table - Payment ID should be non-nullable. For new payments, we'll request a new payment id from the repository. We want to get away from Doctrine automagically creating IDs (see https://matthiasnoback.nl/2018/05/when-and-where-to-determine-the-id-of-an-entity/). Suggested implementation: add a `getNextId()` method to the `PaymentRepository` interface. See https://stackoverflow.com/questions/26578313/how-do-i-create-a-sequence-in-mysql on how to create sequences with MySQL. - Since the relation of payment and payment method is 1:1. reuse the payment id both as primary key and foreign key for the payment method tables - The database table index for `PaymentReference` should include both fields. You might translate the payment type to an integer or MySQL ENUM (see https://www.doctrine-project.org/projects/doctrine-orm/en/2.9/cookbook/mysql-enums.html) to avoid storing and comparing the same string vor and over - You might leave out the Payment methods outlined in the data model. They are convenience functions that call the different methods on the `PaymentMethod`

This is the parent task for refactoring the data model of the payment domain and adding a repository implementation that can read and write the data model to a database. Acceptance Criteria - The domain objects are refactored according to the [[ https://raw.githubusercontent.com/wmde/fundraising-payments/master/docs/data_model.svg | data model ]] - There is a `PaymentRepository` interface with methods for getting a payment and storing a payment - There is an implementation of the interface that stores the data in normalized database tables Implementation details Start with the credit card data implementation to get a model of average complexity, then implement the other payments with external providers in the same fashion. Then do the non-internal payments.

Additionally to our `PaymentMethod` classes we'd like to create a `Payment` class that takes over the payment-related of the fields and responsibilities of the `Donation` and `Membership` classes. Also,This is the parent task for refactoring the data model of the payment domain and adding a repository implementation that can read and write the data model to a database. we would like to store payments and all the data associated with the payment method in separate database tables Acceptance Criteria - The domain objects are refactored according to the [[ https://raw.githubusercontent.com/wmde/fundraising-payments/master/docs/data_model.svg | data model ]] - There is a `PaymentRepository` interface with methods for getting a payment and storing a payment - There is an implementation of the interface that stores the data in normalized database tables Implementation details - Each payment method should have its own database table - Payment ID should be non-nullable. For new payments, we'll request a new payment id from the repository. We want to get away from Doctrine automagically creating IDs (see https://matthiasnoback.nl/2018/05/when-and-where-to-determine-the-id-of-an-entity/). Suggested implementation: add a `getNextId()` method to the `PaymentRepository` interface. See https://stackoverflow.com/questions/26578313/how-do-i-create-a-sequence-in-mysql on how to create sequences with MySQL. - Since the relation of payment and payment method is 1:1. reuse the payment id both as primary key and foreign key for the payment method tables - The database table index for `PaymentReference` should include both fields.Start with the credit card data implementation to get a model of average complexity, You might translate the payment type to an integer or MySQL ENUM (see https://www.doctrine-project.org/projects/doctrine-orm/en/2.9/cookbook/mysql-enums.html) to avoid storing and comparing the same string vor and over - You might leave out the Payment methods outlined in the data modelthen implement the other payments with external providers in the same fashion. They are convenience functions that callThen do the different methods on the `Pnon-internal paymentMethod`ts.