Trigger architecture
In the same way that it is a best practice to have only a single Process Builder process or record-triggered flow per object, it is also a best practice to have only a single trigger per object. With multiple triggers, we cannot guarantee their order of execution, which may lead to unintended consequences. With a single trigger, however, we can control the order in which the updates are made as the code will run sequentially within the trigger.
A good question I was once asked when teaching a class on Apex was, Why one trigger per object, rather than one trigger per context per object? That is, why is the suggestion to have an AccountTrigger and not a series of triggers on the Account object, where each manages a single context: AccountBeforeInsertTrigger, AccountAfterUpdateTrigger, and so on? This can be seen in the following diagram:
Figure 3.4 – A single trigger per object versus a single trigger per object per context
...
