Задрали уже со своим Фаулером и его Domain Model. Терминология по Фаулеру выглядит примерно так:
На самом верхнем уровне есть несколько способов построения приложения в зависимости от того, что за приложение реализуется. Варианты — Transaction Script, Domain Model, Table Getway, и что-то там еще...
Далее — камень преткновения вариант Domain Model. Domain Model предполагает, что из объектов городится конструкция максимально похожая на те объекты, которые есть в предметной области. И на практике выясняется, что Domain Model можно реализовать как минимум двумя способами.
1. Поместить логику вместе с данными (Rich Domain Model в терминологии Фаулера)
2. Поместить данные отдельно от логики (Anemic Domain Model в терминологии Фаулера)
Фаулер активно поддерживает первый и бурно возражает против второго.
После некоторого исследования вопроса складывается впечатление, что основной сыр-бор из-за того, что Фаулер, и основная масса бьющихся сторон, упускают из виду один ключевой момент — навигационный доступ.
То есть, есть еще два варианта построения объектов доменной модели
3. Навигационный доступ — Order имеет коллекцию Item-ов
4. Ссылочный — каждый Item имеет OrderId.
Причем последний, уже не совсем объектная модель домена.

Вернемя к Фаулеру. Мартин, критикуя Anemic, в какой-то момент замечает, что это мол уже похоже на transaction Script, при этом собственно против Transaction Script-а он ничего не имеет, но нигде, ни словом не упоминает, чем же этот Transaction Script отличается от Anemic Domain Model. Однако, единственное отличие которое можно придумать — это как раз доступ, в Anemic — навигационный, в TS — ссылочный.
Если принять эту гипотезу за рабочую, то в принципе понятен гнев Мартина — уж коли взялись строить Domain Model, так делайте ее по взрослому, по объектному.
Таким образом выстраивается следующая картина:
1. Rich Domain Model — модель домена с блэкджеком и девками, навигационный доступ и там же логика. Это True Domain Model и по словам самого же Фаулера имеет довольно ограниченную область применения.
2. Anemic Domain Model — модель домена с блекджеком, но без девок, навигационный доступ, но только данные — логика отдельно. Фаулер разносит эту конструкцию, как имеющую все недостатки Domain Model, но не имеющую преимуществ Rich. (что это за преимущества отдельный вопрос)
3. Transaction Script ?? (или, кстати, Table Getway, так как бизнес-объекты уже больше похожи на то что есть в БД, а не в предметной области) — блэкджек отдельно, девки отдельно. Доступ ссылочный, бизнеслогика отдельно. Фаулер конечно кривится, из-за того, что по его мнению это сильно похоже на процедурный стиль, но в целом признает, что это работает.
4. ??? — Девки без блэкджека. Тоже вариант, наверное.

Ну и раз у нас тут стало модно, про себя:
Лично я не являюсь приверженцем ни одной вышеозначенной модели, и обычно, при проектировании, пользуюсь более фундаментальным принципом — если метод пользуется только публичным контрактом некоего класса, то его нужно помещать вне этого класса. На практике это выраждается в что-то очень похожее на пункт 3.
Хотя я теоретически допускаю вероятность того, что при таком подходе получится и 1, но в живой природе я таких зверьков без серьезных косяков не встречал.