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 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, 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.