Единственный Принцип Ответственности по сравнению с Анемичным антишаблоном Модели предметной области

I've found following the solid principles did in fact lead me away from DDD's rich domain model, in the end, I found I didn't care. More to the point, I found that the logical concept of a domain model, and a class in whatever language weren't mapped 1:1, unless we were talking about a facade of some sort.

I wouldn't say this is exactly a c-style of programming where you have structs and modules, but rather you'll probably end up with something more functional, I realise the styles are similar, but the details make a big difference. I found my class instances end up behaving like higher order functions, partial functions application, lazily evaluated functions, or some combination of the above. It's somewhat ineffable for me, but that's the feeling I get from writing code following TDD + SOLID, it ended up behaving like a hybrid OO/Functional style.

As for inheritance being a bad word, i think that's more due to the fact that the inheritance isn't sufficiently fine grained enough in languages like Java/C#. In other languages, it's less of an issue, and more useful.

Мне нравится определение SRP как:

«У класса есть только одна бизнес-причина для изменения»

Итак, пока поведение можно сгруппировать в отдельные «бизнес-причины» тогда у них нет причин не сосуществовать в одном классе. Конечно, то, что определяет «деловую причину», открыто для обсуждения (и должно обсуждаться всеми заинтересованными сторонами).

Модель расширенной области (RDM) и принцип единой ответственности (SRP) не обязательно противоречат друг другу. RDM больше расходится с очень специализированным подклассом SRP - моделью, защищающей «компоненты данных + вся бизнес-логика в классах контроллеров» (DBABLICC).

Если вы прочитаете главу Мартина SRP , вы увидите, что его пример модема полностью находится на уровне домена, но абстрагируется от концепций DataChannel и Connection как отдельных классов. Он хранит сам модем как оболочку, поскольку это полезная абстракция для клиентского кода. Это гораздо больше о правильном (ре) факторинге , чем о простом расслоении . Сплоченность и сцепление по-прежнему являются базовыми принципами дизайна.

Наконец, три проблемы:

• Как отмечает сам Мартин, не всегда легко увидеть различные «причины перемен». Сами концепции YAGNI, Agile и т. Д. Препятствуют ожиданию будущих причин для изменений, поэтому нам не следует изобретать те, где они не сразу очевидны. Я рассматриваю «преждевременные, ожидаемые причины для изменений» как реальный риск при применении SRP, и разработчик должен управлять им.

• В дополнение к предыдущему, даже правильное (но ненужное анальное ) применение SRP может привести к нежелательной сложности. Всегда думайте о следующем бедолаге, которому придется поддерживать ваш класс: действительно ли старательная абстракция тривиального поведения на его собственные интерфейсы, базовые классы и однострочные реализации поможет ему понять, что просто должно быть одним классом?

• Дизайн программного обеспечения часто сводится к нахождению наилучшего компромисса между конкурирующими силами.Например, многоуровневая архитектура в основном является хорошим применением SRP, но как насчет того факта, что, например, изменение свойства бизнес-класса, скажем, с логического на enum имеет волновой эффект на всех слоях - от базы данных до домена, фасадов, веб-службы и до графического интерфейса пользователя? Указывает ли это на плохой дизайн? Не обязательно: это указывает на то, что ваш дизайн способствует изменению одного аспекта изменения другого.

Преобразуйте ваши обычные доменные объекты в шаблон ActiveRecord с общим базовым классом для всех доменных объектов. Поместите общее поведение в базовый класс и переопределите его в производных классах, где это необходимо, или определите новое поведение, где это необходимо.

Цитата из документа SRP очень верна; SRP трудно получить правильно. Этот и OCP являются двумя элементами SOLID, которые просто должны быть смягчены, по крайней мере, до некоторой степени, чтобы на самом деле выполнить проект. Чрезмерное применение любого из них очень быстро приведет к созданию кода равиоли.

SRP действительно может быть доведен до смехотворного, если «причины для изменения» слишком конкретны. Даже «пакет данных» POCO/POJO можно рассматривать как нарушение SRP, если вы рассматриваете тип изменения поля как «изменение». Вы могли бы подумать, что здравый смысл подскажет вам, что изменение типа поля является необходимым допуском для «изменения», но я видел слои предметной области с оболочками для встроенных типов значений; ад, по сравнению с которым ADM выглядит утопией.

Часто бывает полезно поставить перед собой какую-то реалистичную цель, основанную на удобочитаемости или желаемом уровне связности. Когда вы говорите: «Я хочу, чтобы этот класс делал одно дело», он должен иметь не больше и не меньше того, что необходимо для этого. Вы можете поддерживать по крайней мере процедурное единство с этой базовой философией. «Я хочу, чтобы этот класс поддерживал все данные для счета-фактуры», как правило, позволяет НЕКОТОРУЮ бизнес-логику, даже суммирование промежуточных итогов или расчет налога с продаж, на основе ответственности объекта знать, как дать вам точное, внутренне согласованное значение для любого поля это содержит.

Лично у меня нет большой проблемы с «облегченным» доменом. Просто наличие одной роли «эксперта по данным» делает объект предметной области хранителем каждого поля/свойства, относящегося к классу, а также всей логики вычисляемого поля, любых явных/неявных преобразований типов данных и, возможно, более простых правил проверки. (т. е. обязательные поля, ограничения значений, вещи, которые могут привести к внутренней поломке экземпляра, если это разрешено). Если алгоритм вычисления, возможно, для взвешенного или скользящего среднего, может измениться, инкапсулируйте алгоритм и ссылайтесь на него в вычисляемом поле (это просто хороший OCP/PV).

Я не считаю такой доменный объект «анемичным». Мое восприятие этого термина — это «мешок данных», набор полей, который не имеет никакого представления о внешнем мире или даже об отношениях между его полями, кроме того, что он их содержит. Я тоже это видел, и не очень весело отслеживать несоответствия в состоянии объекта, о которых объект никогда не знал, что это проблема.Чрезмерно усердный SRP приведет к этому, заявив, что объект данных не отвечает за какую-либо бизнес-логику, но здравый смысл обычно вмешивается первым и говорит, что объект, как эксперт по данным, должен нести ответственность за поддержание согласованного внутреннего состояния.

Опять же, личное мнение, я предпочитаю шаблон Repository Active Record. Один объект, с одной ответственностью, и очень мало, если что-то еще в системе выше этого уровня, должно знать что-либо о том, как это работает. Active Record требует, чтобы уровень предметной области знал по крайней мере некоторые конкретные сведения о методе сохранения или структуре (будь то имена хранимых процедур, используемых для чтения/записи каждого класса, ссылки на объекты, специфичные для среды, или атрибуты, украшающие поля информацией ORM). ), и, таким образом, добавляет вторую причину для изменения в каждый класс предметной области по умолчанию.

Мои 0,02 доллара.