When creating your data model, there are several principles that can be used. One of them is the KISS method: Keep it Super Simple (which is a better alternative than Keep it Simple, Stupid).
Here are some considerations when applying this principle:
Standard Objects
When the functionality you’re trying to build fits about 80% of the existing data model and built-in functionality. For example, using Opportunity to track donations makes sense, as they both use a closing date, an amount, and a stage.
But if what you’re trying to build doesn’t use those fields, perhaps the Opportunity isn’t an appropriate object to use.
Standard Fields on Standard Objects
Opportunity.CloseDate may not make sense in your context. So also consider renaming fields. Perhaps Start Date is a more appropriate label.
Custom Fields on Standard Objects
If 80% of fields and functionality of a standard object works for you, then the remaining 20% can often be achieved with custom fields. Just be sure they don’t already exist.
For example, I’ve seen orgs create Contact.Gender__c when GenderIdentity already exists. It’s just hidden from everyone’s permissions (for who knows what reason!)
Custom Objects
When the above fails, then it’s time for custom objects. This provides maximum flexibility. Just keep the same naming convention as standard objects so it doesn’t feel like a custom object to your users.
The takeaway
Try to fit your data model into existing objects and fields before creating custom ones.