Модель предметной области: должны ли в ней присутствовать такие вещи, как логирование, аудит, постоянство

Question

Мне трудно убедить нашего архитектора в том, что модель предметной области должна содержать только основные элементы бизнес-предмета. Такие вещи, как тот факт, что класс является постоянным, что он требует ведения журнала и аудита и что он имеет RESTful URI, не должен управлять моделью домена. Они могут быть добавлены позже, используя интерфейсы.

Наша система управления медицинской информацией. На очень грубом уровне - это система, в которой пользователи входят и получают доступ к своей медицинской информации. Они могут делиться этой информацией с другими и быть хранителем информации других (подумайте о ролях). Но из-за нескольких звуковых байтов, которые завоевали популярность раньше - «Все должно быть ресурсом REST» - модель теперь имеет класс верхнего уровня под названием Resource, из которого расширяется каждый другой класс.

Я пытаюсь убедить его, что модель предметной области должна основываться на четко определенных понятиях, таких как учетная запись пользователя, HealthDocument, UserRole и т. Д., Которые являются различными субъектами бизнеса, с конкретными ассоциациями между ними. Объединение всего в класс Resource позволяет нашей модели быть негибкой, помимо потенциально неправильной - если все является «ресурсом», то как можно изобразить понятие «пользователь, получающий доступ к ресурсу».

Но он хочет, чтобы я показал ему, почему плохая идея делать это по-своему. Я не знаю, как правильно сформулировать это, но все мои ОО-инстинкты говорят мне, что это просто неправильно. Есть мысли?

Answer 1

Я думаю, вы должны уволить своего архитектора.

Тот факт, что все в REST является ресурсом, не означает, что все ваши классы должны быть производными от "ресурса"!

Нет, эти зависимости реализации не должны быть частью модели предметной области. Напомните своему архитектору, что модель предметной области должна быть одинаковой, даже если вы внедрили код с другой технологией, например, SOAP.

Answer 2

ИМХО с точки зрения ОО, если бы вы моделировали систему (не программное обеспечение), у вас были бы все концепции предметной области, их отношения и поведение в модели. Модель домена, как и в многоуровневой архитектуре, Domain Driven Design и даже Model View Controller - это реализация именно того, что я описал. Таким образом, модель предметной области не содержит технических деталей. Для чего хорошо это разделение? Зачем его использовать? Одной из причин является удобочитаемость кода, когда вы отделяете бизнес-логику от технических аспектов, вы можете легко определить, как работает один или другой, не будучи нарушенным другим. Другая причина - независимость от технической платформы. Время от времени может потребоваться, чтобы ваша система претерпела некоторые технологические изменения, которые будут проще, когда вам нужно будет только изменить их в одном месте. Другая причина - гибкость бизнеса - способность изменять работу бизнес-логики (вещи, указанные в модели системы) без необходимости технологических изменений. Это использование принципа разделения задач ОО.