In most systems I encounter there is a strong focus on "Entities". We try to model everything in this "Entity" abstraction where one "Entity" is typically mapped to one table.
Every piece of data that is related to this "Entity" is encapsulated in this object. This could sound fine from a OO perspective but can bring us on a path where we get too much coupling and information from multiple domains get encapsulated in the same object.
A first step in the right direction is to focus on the difference between related entities and child entities. Could some parts of the data move to a child entity or even a value object?
A second step is to identity your bounded contexts and start to split your entity across the boundaries of these contexts. This means you will typically not end up with one entity but many entities each containing a subset of the data.
Let's take a look at an example...
Imagine that we have a Product entity.
If we try to split this across the context boundaries, we could end up with something like this:
This not only allows us to encapsulate the logic a lot better, it gives use a more evolvable system where changes in one context don't impact another.