The authors build a small application and keep adding structure to it: they separate the business model from the database, insert a service layer, define units of work, group objects into aggregates with a consistency boundary, and finish with events and a message bus. Every pattern arrives with its justification and, gratifyingly, with its cost.
What I took from it
The aggregate and its consistency boundary is what I use most, not for writing code but for design. Asking which things must change together, or must not change at all, is what sorts out a data model: an order and its lines change together; an order and the customer's balance need not. When a company reports inconsistent data, somebody usually drew that boundary in the wrong place.
The second: the service layer as the place where business rules live, away from the screen and away from the database. Inside an ERP the temptation is to put the logic in the button, and that logic becomes invisible the day someone creates the same record through an import or an interface.
And the third, which the authors state honestly: every pattern adds indirection. If the team is one person and the system is small, half of them are not worth it.
What I left out
A good deal, for a specific reason: working inside an ERP is not working with free hands. The framework brings its own data access, its own unit of work and its own conventions, and fighting it to impose a hexagonal architecture produces code no later consultant will understand. What I carry over are the questions; the literal implementation stays behind.