I think this article ignores or glosses over the hardest part about naming, which is when you have to start naming things with abstract behavior. Naming things with analogs in the domain is easy, but when you find yourself trying to follow the Single Responsibility principle and breaking pieces off you run into trouble.

My AccountingRow is something the user sees, and there's also a SummaryAccountingRow with similarities; both of these need SQL generated, so there's a AccountingRowSQLGenerator and a AccountingRowSummarySQLGenerator. These generally share some of the same business logic around how to join different tables, so there's a AccountingRowCommonQueries class. We also need to spit this out in JSON, so there's a AccountingRowSerializer and AccountingRowsSerializer and AccountingRowSummarySerializer, AccountingRowSummaryRowsSerializer. An AccountingRow also has an AccountingRowBehavior, and AccountRowAdder, and onward into infinity.

Now you have name soup, and if you are looking at this system for the first time your eyes glaze over.