- Separate business layer from data layer
- Synchronize an additional field 'bonusPointsBalance'
- Update the existing tests to verify that bonusPointsBalance is updating correctly
- Introduced interfaces for potential future extensibility
- Structured the application by breaking it into packages
- Removed unreachable code
- Removed unnecessary if statement
- Get rid of duplicate code
- Get rid of hard-coded strings and used enum instead
- Reduce code complexity and improve code readability by introducing several new methods
I don't like the way we are updating duplicates one by one in the for each loop. If it weren't for a 'fakeDatabase,' I would refactor it to perform the save operation in 'bulk' so that there would be only one SQL statement. In the case of using OracleDB, we could update 1000 customers in one batch instead of hitting database 1000 times.
ExternalCustomer uses the same "Address" and "ShoppingList" as a Customer, which might pose a problem in the future. In the event that a Customer or ExternalCustomer undergoes changes and no longer aligns with the Address / ShoppingList, resulting in BC-compatibility issues, it's advisable to implement an additional mapping layer between them. In case we would like to be more flexible I would use ExternalAddress and ExternalShoppingList and map them (e.g. using mapStruct) to enhance flexibility between Customer and ExternalCustomer. However, for a simple exercise like this, I opted not to make it overly complex or invest too much in future considerations.