Change Details

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.

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. We discussed how to model the data shared across payments: Via composition (a payment consists of an amount and a duration and //has a// payment data object that defines what can be done with the payment) or inheritance (there //are different kinds// of payments with different properties, but that expose the same interface? We decided to use inheritance because * "Composition over Inheritance" is a strict dogma that only applies when inheritance is misused to share technical implementation details (see https://www.thoughtworks.com/insights/blog/composition-vs-inheritance-how-choose ) * It's easier to implement with Doctrine, [[ https://www.doctrine-project.org/projects/doctrine-orm/en/2.11/reference/inheritance-mapping.html#class-table-inheritance | Inheritance Mapping with Class Table Inheritance ]] * When describing the domain, the name "PaymentMethod" felt weird and when trying to find alternative names we kept getting "weak" suffixes like `Data` as descriptors, inidcating that the "Data" is not standalone and makes the domain harder to comprehend.

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. We discussed how to model the data shared across payments: Via composition (a payment consists of an amount and a duration and //has a// payment data object that defines what can be done with the payment) or inheritance (there //are different kinds// of payments with different properties, but that expose the same interface? We decided to use inheritance because * "Composition over Inheritance" is a strict dogma that only applies when inheritance is misused to share technical implementation details (see https://www.thoughtworks.com/insights/blog/composition-vs-inheritance-how-choose ) * It's easier to implement with Doctrine, [[ https://www.doctrine-project.org/projects/doctrine-orm/en/2.11/reference/inheritance-mapping.html#class-table-inheritance | Inheritance Mapping with Class Table Inheritance ]] * When describing the domain, the name "PaymentMethod" felt weird and when trying to find alternative names we kept getting "weak" suffixes like `Data` as descriptors, inidcating that the "Data" is not standalone and makes the domain harder to comprehend.