Khononov organises the subject on two planes. The strategic one: which parts of the business set the company apart, which support it, which are the same everywhere; where one model ends and another begins; how two systems that do not speak the same language get integrated. The tactical one: how you write that in code. The first is what matters to anyone working with an ERP.
What I took from it
The split into core, supporting and generic subdomains is what I use most, because it settles the argument about what gets built and what gets left alone. Generic things — basic accounting, email, signatures — do not get built: anybody does them better. What sets the company apart is the only thing that justifies custom code and ten years of maintenance. Since then, faced with a development request, my first question is not whether it can be done but whether this is what makes the company different; when the answer is no, the conversation turns to configuration.
The second idea I took is the translation layer at the border. When you have to integrate with an old system, the worst outcome is its vocabulary leaking into the new one and contaminating it: a field with three meanings depending on the case, a status nobody can define. Translation happens at the edge, deliberately, with one place where the ugliness lives.
The third is that model boundaries are also conversation boundaries. When two departments use the same word for two different things, forcing a single meaning usually costs more than accepting two models and translating between them.
What I left out
Much of the tactical plane. Aggregates, event sourcing and separating reads from writes are meant for building a system from scratch with your own objects. An ERP arrives with its model, its transactions and its way of persisting; layering these patterns on top means fighting the tool.