По-моему, ошибка состоит в наивном "моделировании" предметной области с помощью об'ектов. Типа, раз я имею дело с байтами, битами, портами, аппаратными интерфейсами и проч., то надо создать соответствующие классы.

А на самом деле ООП это инструмент (один из) чтобы "правильно" организовать/структурировать программу (computation). Собственно, ругательски ругаемый нынче ГоФ это и показал: У нас же в предметной области нет "фабрик", "синглетонов" и "команд". А классы такие есть. И встречаются в самых разных предметных областях.
 ivan-gandhi.livejournal.com/2844985.html

именно.

Ошибка преподавания и использования ООП в моделировании предметной области.

А надо бы "разобрать" предметную область на составляющие, и моделировать их.
а описание в коде предметной области - собирать из этих составляющих.

на примере обычного языка:

ООП сейчас часто применяется как:
видим в предметной области:
"... в наивном ..."
аха, вот он класс Naively
встречаем
"... в наивных ..."
аха, наследуемся
встречаем
"... это наивно ..."
аха... соображаем что наверное это базовым классом должно быть - Naively. переделываем.

встречаем
"... глупо ..."
новый класс

итого, получаем на вид описание предметной области, а на деле ее "хардкодинг"
и когда в ней появляется нечто ранее неизвестное, или упущенное - приходится громоздить новые классы, перекрывая старые.

а надо бы
1. либо проектировать от правил - части речи, падежи
2. либо, "статистически" от букв, слов, порядка слов, устойчивых связок слов

то есть, предоставить более абстрактные, мелкие классы - для выражения утверждений предметной области.
именно в этом суть совета строить не наследованием - B is A, а композицией: В has A

для примера - холивар Rich vs Anemic

3ий подход - DSL, к ООП как таковому не имеющий отношения, а просто по той же идее - дайте с чего собирать утверждения предметной области.