Model timelines not entities
Going all the way back to when I was at university, I was taught to model entities or objects. Given a problem, I would be told to look for things like 'cars' and 'people' and model them in some glorified hierarchical structure making use of inheritance.
This continued well into my professional career, and although I personally have changed, I still see this way of modelling everywhere. For simple systems, this will be fine. But as the complexity of your domain grows, it often leads to a god object.
If you model an entity, you are, by design, modelling something that will live for a very long time. For example, in a hospital, you could model a patient. But there are numerous actions you can perform against a patient that will cause the entity's size to grow. Before long, you'll end up with a large patient object backed by a large data graph in the database, which is terrible.
Having large entities like this in your system makes things difficult to change. You'll have more side effects to consider when refactoring, and changing the design will be difficult.
A better option is to model the business process instead of modelling the entities. Using the patient as an example, you can model the patient's journey through the hospital instead. You can model an admission or discharge as an individual process. Some of these models will be large and some small, but they will all share something in common: they will be temporal. They have a beginning and an end.
This makes it easier to control the boundaries and stop them from becoming large god objects. It also brings with it other advantages. Most notability that this is how people think. Businesses think in processes, and if you can model that in code.
One thing to consider with this approach is that you'll need a good understanding of the domain. You need to have domain experts at your disposal because otherwise, you'll just be a bunch of developers guessing at how the business works without them.
If you do have access to the domain experts, I'd highly recommend Event Storming as a method for discovering these processes. It's an excellent way for domain experts and developers to interact, and I recommend reading Alberto Brandolini's book on the subject.
Finally, this way of thinking works incredibly well when building event sourced systems, as these often suffer from the same problem. When developers model the entities, they usually have massive streams that take a long time to hydrate. Modelling the processes will keep these streams short and give you the option to dispose of them when they are no longer relevant.