Domain model + Data mapper + Service Layer

Блог им. bobo
Всем привет. После прочтения кучи материалов из книг и интернета образовалась каша в голове, и путаница в терминах. Может есть кто особо просвещенные? В инете много бесед по этому поводу, но все они обрываются на самых интересных местах без ответа. Начнем…
Для простоты и понимания предлагаю сначала нивелировать все обсуждение на livestreet. Проблема в организации модели данных. На сколько я могу понимать в livestreet используется domain model(с минимальной логикой домена) + data mapper. (Это паттерны из Фаулера) Смотрим ссылку , тут человек пишет, что в модели должен быть еще сервисный слой. Если я правильно понимаю, то в livestreet — это главный файл модуля. Но по Фаулеру сервисный слой это совсем другое, и применительно к livestreet — этот слой был бы прослойкой между контроллером и главным файлом модуля. То есть контроллер дергал был сервисный уровень, а уровень уже модуль.
Вопросы:
1) Правильно ли я понимаю картину?
2) Чем на самом деле является главный файл модуля? К чему его относить? К domain model?

21 комментарий

avatar
Ну вот в статейке которую вы дали отличное описание модели.
Модель— это объект, предоставляющий некоторую информацию о домене. У модели нет визуального интерфейса, она содержит в себе все данные и поведение, не связанные с пользовательским интерфейсом.
Вполне подходит для модуля LS
avatar
По-моему как раз из статьи, нивелируя на livestreet, речь идет о том, что главный файл модуля = сервисный слой.
avatar
Чего не должно быть по Фаулеру, как я понял. Вот я о чем.
avatar
Сервисный слой это связующее звено между различными подсистемами приложения. Между Доменом и Источником Хранения, Доменом и Контроллером, Доменом и Представлением.
Это не сервисный слой.
Чего не должно быть по Фаулеру, как я понял. Вот я о чем.
Не все должно быть по Фаулеру =)
avatar
Не все должно быть по Фаулеру =)
Вы как раз подтвердили обратное пока — то не сервисный слой.
Кроме того с моей кашей в голове сейчас, я не могу понять, что вы хотите сказать. Давай выражаться более полными предложениями, дабы еще больше не запутаться, кто и что имеет в виду =)
avatar
Главный файл модуля != сервисный слой. Хотя он и выполняет связующую функцию между маппером и файлом экшна в нем так же реализуется логика не связанная с обработкой действий пользователя напрямую.

Поэтому объектная модель ЛС не на все 100% соответствует предложенной М. Файлером =)
avatar
Фаулер как раз и пишет, что это не есть сервисный слой. К какому слою по-вашему относится главный файл модуля?
avatar
Опять же в статейке выше.
1. Слой Бизнес-логики (Bussines Logic Layer)
2. Сервисный Слой (Service Layer)
3. Слой Источника Данных (Data Source Layer)
Я бы сказал что файл модуля это 1 + 2
avatar
Мы же определились, что это не сервисный слой. Как тогда правильно это назвать? (второй пункт)
avatar
Правильно назвать его главный файл модуля ЛС =)))
Он реализует функции BLL и SL.
avatar
Хорошо, допустим возьмем какой-нибудь еще фреймворк, kohana, zend или yii. И попробуем сделать изначально все правильно. Хотим мы сделать новости, каждая новость привязана к категории. Решили за основу взять паттерн domain model + data mapper для связи с источником данных. Что должна включать в себя модель по Фаулеру?
avatar
Ну в Zend сообществе много раз обсуждали эту тему.
Мне кажется что примерно нам понадобится в произвольном порядке

  • Класс вида
  • Контроллер
  • Наследник DBTable для «ворот» в БД
  • Домен
  • Сервис
avatar
Приведите, пожалуйста, ссылки на обсуждение. Я сам с зендом не работал — поэтому сообщество не мониторю. Сервис — это я так понимаю не сервисный слой, который описан в паттернах у Фаулера?
avatar
В данном случае как раз он. Как раз он будет доступен во всех компонентах которые нам надо слепить вместе.

Насчет обсуждений
zendframework.ru/forum/index.php?topic=2303.0

первые страницы стоит прочитать. В свое время мне самому немного прояснили, когда я после ZFшного quick start'a пытался более серьезные вещи заставить работать )
avatar
Спасибо, сейчас почитаю.
avatar
Ну вот как раз то, что и было описано в стартовом топике — народ решил, что надо посмотреть простую реализацию на примере — а то все под конец до конца запутались, а дальше еще и валидацию полезли, не определившись с основными понятиями. Дополнительную смуту в наш с вами разговор внесло то, что я ссылался на блог участника дискуссии, ссылку на которую привели вы. Он там с сервисным слоем и слоем приложения всех и добил. =) Точки так и не поставили — а хочется посмотреть пример и знать как все-таки правильно делать.
avatar
«Правильно» не бывает
avatar
Это уже если смотреть глобально. Какая-то общая схема реализации вполне имеет место быть.
avatar
Чем вам не нравится схема реализации на ЛС? Или других CMS, CMF, фрейморках?

Хочется Фаулера 1 в 1? Разделите модуль на сервисный слой и логику и вуаля.
Ну может быть еще изначально доступ маппера, например к сущности не «православен» или еще какие то запросы следует пускать через сервис.
Во всем этом нет смысла, если у вас нет конкретной ситуации, в которой существующая схема не предоставляет достаточной гибкости или мешает скорости работы приложения.
avatar
Я первый топик-то писал не просто так. Говорю же каша в голове образовалась. Вот чем реализация в ЛС не по Фаулеру?
avatar
Такие обсуждения каши в голове кому угодно добавят )
Я может ошибаюсь, но не помню, чтобы Фаулер давал указания по построению архитектуры от и до. Но зато у него есть Service Layer
который
Сервисный слой - является проводником к Доменной Модели. Все взаимодействия с Доменом должны осуществляться через Сервисный Слой.


Этого в ЛС нет по сути.
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.