Change Details

**Acceptance Criteria** - The domain objects for bank data payments are refactored according to the data model. You can leave other payment objects in a semi-broken state as long as all remaining tests still pass and the next steps are clear (i.e. putting TODOs/commented-out code in classes, skipping tests). - The implementation of the `PaymentRepository` interface implements storing and retrieving payments with direct debit. All other payment methods may throw "Not implemented" logic exceptions for now. **Implementation Details** - Refactor `BankData` as needed, dropping the `FreezableValueObject` trait and creating a proper class that gets all dependencies through the constructor. - Drop the legacy bank account and bank number data. We don't need to store those and can reproduce them (if needed for display/mailing purposes) through the kontocheck api.

**Acceptance Criteria** - The domain objects for bank data payments are refactored according to the data model. You can leave other payment objects in a semi-broken state as long as all remaining tests still pass and the next steps are clear (i.e. putting TODOs/commented-out code in classes, skipping tests). - The implementation of the `PaymentRepository` interface implements storing and retrieving payments with direct debit. All other payment methods may throw "Not implemented" logic exceptions for now. **Implementation Details** - Refactor `BankData` as needed, dropping the `FreezableValueObject` trait and creating a proper class that gets all dependencies through the constructor. - Drop the legacy bank account and bank number data. We don't need to store those and can reproduce them (if needed for display/mailing purposes) through the kontocheck api. - For data protection reasons, IBAN and BIC must be nullable properties, introducting an "anonymized" state. The constructor with nullable arguments. There should be a public static factory method with required arguments to ensure that we construct an initially valid direct debit payment ("new payments need data").

**Acceptance Criteria** - The domain objects for bank data payments are refactored according to the data model. You can leave other payment objects in a semi-broken state as long as all remaining tests still pass and the next steps are clear (i.e. putting TODOs/commented-out code in classes, skipping tests). - The implementation of the `PaymentRepository` interface implements storing and retrieving payments with direct debit. All other payment methods may throw "Not implemented" logic exceptions for now. **Implementation Details** - Refactor `BankData` as needed, dropping the `FreezableValueObject` trait and creating a proper class that gets all dependencies through the constructor. - Drop the legacy bank account and bank number data. We don't need to store those and can reproduce them (if needed for display/mailing purposes) through the kontocheck api. - For data protection reasons, IBAN and BIC must be nullable properties, introducting an "anonymized" state. The constructor with nullable arguments. There should be a public static factory method with required arguments to ensure that we construct an initially valid direct debit payment ("new payments need data").