Dealing with entities customization

Question

I suppose every project that is considered as huge and diversed into a lot of parts (admin side, widgets, API, website with a lot of stuff and management) can finally encounter that it is actually hard to use only one or several entities by some type everywhere. E.g. let's take booking entity in action. We have some general entity that have all needed information actually, but somewhere we do need shortened or filled with additional information entity to not modify existing entity. Here are detailed examples:

Booking entity:

• id
• name
• payment type

Extended with payment detailed information:

• id
• name
• collection of data regardimg payment type (date when it was done/confirmed/deleted etc, name of buyer, amount of bought items etc)

...and many many more

What is the most logical way to deal with this? Creating a lot of entities to suit every case the most, or make basic entity extendable in some way?

Update 1: The actual question is not about validation of fields or something. The question is about situation when you have a lot of similar entities for different purposes, and how you usually handle such things.

• Walfrat: For your sample, you can handle this by composition an entity "DetailedBookingPayment" which contain a reference to the entity Booking and the specific fields. This pattern is really easy to apply as long as the entities live independantly from each other.
• Laiv: Maybe, it's time for a design review. After a while the original levels of abstraction could have been blurred by code that didn't fit in the original design. So, step back and look at the problem with more perspective. Sometimes we can not see the wood for the trees.

Answer 1

I would seperate paymentinfo/deliveryinfo/customerInfo/.... from booking/ordering.

advantages:

• you can handle the usecase hasNotPayedYet (booking has no paymentinfo)
• you can handle the usecase subpayments (i.e. 80% has to be payed 14 days after booking, the rest 2 weeks before the travel starts)
• you can change payment-implementation-details without affecting other moduls.
  • example you can later add more different paymenttypes (i.e. creditcard, pay-on-delivery, paypal, advance, ....) with their specific fields.

Answer 2

The most logical way to deal with this has to do with the answers to these questions:

What if the booking entity has a name, name of buyer, but no date? What if it's the name of buyer that's missing? Is an empty string a valid name? How about a dash?

I don't really see the case for types made here. If you had told us the different way these different entities would be used maybe I could see it. You might have a situation where you want to validate the data differently but we don't have a single good indicator of when.

The acid questions to ask here: when these values aren't provided do you have good default values for them? What value's are truly required?