Is it smart to create events like CaseInserted__e for all the possible objects i need to track, or is is smarter to have a general SObjectInserted__e event?
Generally, use one event for each unique type of event. Even though you're just using them in triggers right now, eventually you might decide to integrate with other systems, and they might only want some of the events (e.g. Cases but not Contacts). It's worth the time to split them up now.
If so, I would have to handle them in a dispatcher-like triggerhandler, is that a good approach? Idk. both ways still seem like an overhead to me :(
You can use an Apex Class to consolidate common code, and call them from each trigger. There's no need to write each trigger all over again and maintain separate copies of code.
Are platform events a good approach to win the fight against limits?
Yes, they can be used to combat limits, but please keep in mind that they cannot be rolled back. This means that if you fire off an event, and later use addError to prevent saving a record, you can't undo the event, so your trigger may operate erroneously.
If so, why are they coming in batches and not one by one? this confuses me the most :( Do I always have to consider my self if I need to split them or just publish the whole batch of events?
Triggers always execute in batches of 200 for efficiency. Just publish as many events as you need, the platform will take care of the rest for you. Executing one at a time would be a tremendous waste of resources; this was already learned the hard way in 2007 or so when they introduced Apex Code and Triggers. Back then, triggers only worked on one record at a time, and it caused mass updates to be incredibly inefficient.
If I decide to use the events to decouple the code base, what kind of things should be done in regular triggers and what am I supposed to do in the events triggers?
Validation and before-commit logic should happen in regular triggers for efficiency. Updating parent or child records can generally be done asynchronously, so they're the best candidates for platform events. However, complicated calculations that don't need to be done immediately could also be a candidate for Platform Events, even if it means you have to save over the same record more than once.
Will there even be a need of regular triggers anymore, or should they be replaced, or just do simple stuff like updating fields?
Anything that needs to happen in real time needs to be in the basic triggers, as mentioned above.
Even though it depends on teams to teams when it comes around best practices, but as for your question
Any thoughts on what makes for good naming conventions for a pile of Custom Labels?
I have usually taken an approach of reflecting the intent of the custom label in its name. Have also tried to keep the naming convention seamless so that it can be organized. I have mostly used below approach from best practices around naming conventions of custom labels:
- Use uppercase letters
- Separate words within the name using an underscore
- Reflect the intent/characteristic of the label
- Keep the overall length of the label name short
As an example, let's say if I have a some sort of legal text to be displayed somewhere, I would create a custom label as say, LEGAL_DISCLOSURE_TEXT. Similarly if I had something related to say finance, I would have it as FINANCE_COLLECTION_DAYS.
Again, it all depends on which approach you take, but usually starting right from design helps it from future maintainability and scale-ability perspective.
Best Answer
While I'm not an architect, and haven't seen nearly as many acquisitions (and have been on the acquiree side more often than not), one thing that I/my boss have used in evaluating more routine requests is this:
Who will this change affect?
Many changes that we can make (such as re-labeling objects and fields) can end up affecting everyone. A change might be valid and valuable for one department, but does it run counter to or harm another department?
Implementing changes that affect everyone means that people need to be trained on that change (and even then, there will still be a period of months where people will make mistakes and need technical support).
What value does making such a change bring, and does it offset the cost to those that need to adjust?
To wrap that up nicely: What is the business case for making such a change, and what value does it bring?
I'd also not underestimate your first point. Any disconnect between the label and the API name is going to cause pain (especially for developers and admins). It's annoying enough when Salesforce does it themselves (looking at you, Assets/Services and OpportunityLineItem/Opportunity Product)
This argument is probably most effective when you use Salesforce for more than just the Lead/Sales pipeline, and less effective if are separate orgs for each team/business unit.