Domain model

Прочитал про этот паттерн Фаулера и Зандстру + просмотрел интернет. Проблема в том, что довольно мало полных примеров реализации или я не увидел в связи с кашей в голове. Может у кого есть или кто-то подскажет как полностью применить данный паттерн. Взять хотя бы простой пример (новости+категории новостей) в связке с любым популярным фреймворком (ci, kohana 3.0-3.1, yii или zend). Понятно, что это слишком простой пример для данного паттерна, но думаю им можно наглядно изобразить применение. Как я понимаю, должно быть примерно так
1) Бизнес-логика — domain-model
2) Источник данных — Data mapper
3) Сервисный слой — связующий
Такая реализация на сколько я понимаю в livestreet. А какая иерархия классов должна быть в применении к фреймворку и где бы посмотреть как это правильно и красиво реализовано.
  • Вопрос задан
  • 4475 просмотров
Пригласить эксперта
Ответы на вопрос 1
zizop
@zizop
По Фаулеру вам необходимо охватить поведение и свойства системы. Есть три варианта:
  • Простой — это классы моделей (ActiveRecord/Zend_Db/Doctrine_Record) инкапсулирующие поведение внутри себя.
  • Сложный — модели инкапсулируют данные и методы доступа к ним (Doctrine_Record) и базовое поведение ОДНОГО экземпляра модели, а сложные (групповые, операции бизнес-логики) операции реализуются в сервисном слое(стр.143 книги Архитектура корпоративных программных решений).
  • Самый сложный — почти вся бизнес-логика уходит в сервисы, которые становятся отчетливым программным интерфейсом API взаимодействия с предметной областью.

В качестве реализации можете посмотреть на Doctrine_Record + Zend_Controller + самописные классы сервисов.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы