Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 97
Дааа, знакомые проблемы.
О чем статья-то?
Ну и да, Data-driven design и domain-driven design к ООП/не-ООП имеют мало отношения, они в первую очередь влияют на выбор общей реализации приложения. И, что важнее, они влияют на выбор способа анализа предметной области (за что я, собственно, и не люблю data-driven).
Ну и да, Data-driven design и domain-driven design к ООП/не-ООП имеют мало отношения, они в первую очередь влияют на выбор общей реализации приложения. И, что важнее, они влияют на выбор способа анализа предметной области (за что я, собственно, и не люблю data-driven).
В целом с вами безусловно согласен, но на практике случается, что Data driven с ООП плохо дружат, хоть и с этим вполне можно жить. Статья от части об этом.
Просто не надо думать, что ООП — это обязательно Domain model. Даже у Фаулера это не единственный способ организации приложения.
Можно иметь чисто ОО-приложение, которое при этом будет поток данных гнать в, простите, DataTable. И ничего.
Можно иметь чисто ОО-приложение, которое при этом будет поток данных гнать в, простите, DataTable. И ничего.
Я кажется и не говорил такое :)
Ну а как решение data vs driven влияет на все остальные области приложения?
Data и domain — это просто два разных подхода, которые удобно использовать каждый в своей ситуации. На практике же, если говорить о «бизнес» приложениях, часто ситуации бывают неоднозначные, вот, ну, и собственно, системный архитектор как раз и должен решать эти проблемы.
Отвечая на ваш вопрос — я не могу сказать, как data или domain влияет на остальное приложение, так как это очень абстрактный вопрос, имхо. Мерой влияния может быть сложность перехода от data к domain и обратно
Отвечая на ваш вопрос — я не могу сказать, как data или domain влияет на остальное приложение, так как это очень абстрактный вопрос, имхо. Мерой влияния может быть сложность перехода от data к domain и обратно
А не надо между ними переходить, смена методологии разработки на живом процессе разработки всегда очень дорого обходится.
В статье написано так, как будто бы Data-driven совсем не требует связей между данными, совсем ничего не моделирует и просто в таблички пишут и читают. И к предметной области не имеет отношения.
У вас внешние ключи используют?
БД можно использовать для моделирования предметной области. Реляционная БД имеет меньше средств для моделирования. Но те, которые имеет — жестче и дают возможность рассматривать данные как некоторый н-мерный куб. Что позволяет быстро создавать любой код, который как угодно вращает куб и получает интересующие вещи.
ООП имеет больше средств для моделирования (хотя и не намного. Даже наследование можно смоделировать таблицами), но при этом ООП похоже на хардкод — при любых изменениях требований, кодирования будет больше.
В общем — Domain Driven — не относится ни к шарпу, ни к SQL. Эванс книгу писал для ООП, но это всего лишь дань моде. Он, кстати, там и указывал об этом. Моделировать предметную область с помощью ООП, причем вида — джава, шарп — это один из вариантов.
Реляционными таблицами тоже можно моделировать предметную область. Причем — это декларативный способ.
У вас внешние ключи используют?
БД можно использовать для моделирования предметной области. Реляционная БД имеет меньше средств для моделирования. Но те, которые имеет — жестче и дают возможность рассматривать данные как некоторый н-мерный куб. Что позволяет быстро создавать любой код, который как угодно вращает куб и получает интересующие вещи.
ООП имеет больше средств для моделирования (хотя и не намного. Даже наследование можно смоделировать таблицами), но при этом ООП похоже на хардкод — при любых изменениях требований, кодирования будет больше.
В общем — Domain Driven — не относится ни к шарпу, ни к SQL. Эванс книгу писал для ООП, но это всего лишь дань моде. Он, кстати, там и указывал об этом. Моделировать предметную область с помощью ООП, причем вида — джава, шарп — это один из вариантов.
Реляционными таблицами тоже можно моделировать предметную область. Причем — это декларативный способ.
А зачем излишне хорошо «дружить с ООП»? ООП что-то говорит про какое-то таинственное «поведение» объектов, но я не слышал, чтобы оно что-то говорило про их взаимодействие.
Не, ну ОК, «поведение» — это когда он один, и других объектов нет. Типа «спрятать окно». Но при усложнении и детализации системы на каком-то этапе неизбежно появится другой объект, и «поведение» превратится во взаимодействие. Превед, редизайн, превед, визитор. Так что рассказки про «поведение» лучше изначально выкинуть как пережиток прошлого.
Не, ну ОК, «поведение» — это когда он один, и других объектов нет. Типа «спрятать окно». Но при усложнении и детализации системы на каком-то этапе неизбежно появится другой объект, и «поведение» превратится во взаимодействие. Превед, редизайн, превед, визитор. Так что рассказки про «поведение» лучше изначально выкинуть как пережиток прошлого.
Эта статья — краткое содержание, этой хорошей книги:
www.ozon.ru/context/detail/id/5497184/
www.ozon.ru/context/detail/id/5497184/
я ее пару месяцев назад перечитывал, да
Тот факт, что у Эванса словосочетание «data-driven design» не встречается, вас не смущает?
нет, не смущает
потому что data driven (или data centric) встречается у других довольно, на мой взгляд, авторитетных гайдлайнах о разработке (например, в гайдлайнах от майкрософта, у них вообще прямое противопоставление идет, мол если у вас приложение простецкое возможно вам стоит обратить внимание на Data Driven)
потому что data driven (или data centric) встречается у других довольно, на мой взгляд, авторитетных гайдлайнах о разработке (например, в гайдлайнах от майкрософта, у них вообще прямое противопоставление идет, мол если у вас приложение простецкое возможно вам стоит обратить внимание на Data Driven)
потому что data driven (или data centric) встречается у других довольно, на мой взгляд, авторитетных гайдлайнах о разработке
Я просто не очень понимаю, как статья может быть пересказом книжки, в которой вообще не упоминается подход, обсуждаемый в статье.
Ну так вы спросите Noofiz почему он так считает.
Статья — не пересказ книжки, статья — пересказ моего осмысления пачки книжек, гуглинга темы, практического опыта. Как-то так.
Статья — не пересказ книжки, статья — пересказ моего осмысления пачки книжек, гуглинга темы, практического опыта. Как-то так.
Еще для сущностей, имеющих данные, но не имеющих поведения, применяют термин Anemic Domain Model.
Подскажите, пожалуйста, примеры open source приложений с Rich Domain — очень хочется посмотреть на реально работающий код.DDDSample, естественно, не в счет. Так же интересен пример BDD. Сам найти не смог.
При anemic'е все проблемы решаемы — если классов сущностей очень много — можно их разделять на области.
Повторное использование кода, как в примере с документом, тоже возможно, но в не в иерархии сущностей домена, а в иерархии репозиториев (слой доступа к данным).
Но самая главная проблема rich, которая озвучена, но не вынесена в отдельный пункт — это:
Вообще тема холиварная )
зы Естественно, imho.
При anemic'е все проблемы решаемы — если классов сущностей очень много — можно их разделять на области.
Повторное использование кода, как в примере с документом, тоже возможно, но в не в иерархии сущностей домена, а в иерархии репозиториев (слой доступа к данным).
Но самая главная проблема rich, которая озвучена, но не вынесена в отдельный пункт — это:
Более того, вы не застрахованы от ошибки при моделировании, что может привести к сложному рефакторингу.потому что пути заказчика и его бизнеса неисповедимы и Enterprise разработка отличается частыми и ощутитмыми изменениями требований, а рефакторить rich домен в такой ситуации становится довольно затратно и рефакторится он в сторону anemic.
Вообще тема холиварная )
зы Естественно, imho.
«Подскажите, пожалуйста, примеры open source приложений с Rich Domain» — не подскажу, ибо сам таких не знаю. Мне кажется «чистый» DDD найти можно только в надуманным примерах.
Проблема анемичной модели в том, что она уходит от ООП. Поэтому если вы программируете в стиле ООП, анемичная модель просто будет инородной деталькой. Хорошо это или плохо — тема холиварная, я довольно много изучал этот вопрос и сталкивался с обилием споров, и у всех есть аргументы :)
Имхо, если разработчик знает суть ddd и dbdd и других «dd», то он осознано может уйти и в анемичную модель, и все у него будет хорошо, но проблема то в том, что многие программисты знают, что такое orm и как нагенерить классов, а вот, что потом с этим делать не знают (или думают, что знают :)
Заявляю это на основании проведенных собеседований.
Проблема анемичной модели в том, что она уходит от ООП. Поэтому если вы программируете в стиле ООП, анемичная модель просто будет инородной деталькой. Хорошо это или плохо — тема холиварная, я довольно много изучал этот вопрос и сталкивался с обилием споров, и у всех есть аргументы :)
Имхо, если разработчик знает суть ddd и dbdd и других «dd», то он осознано может уйти и в анемичную модель, и все у него будет хорошо, но проблема то в том, что многие программисты знают, что такое orm и как нагенерить классов, а вот, что потом с этим делать не знают (или думают, что знают :)
Заявляю это на основании проведенных собеседований.
Поэтому если вы программируете в стиле ООП, анемичная модель просто будет инородной деталькой.
Это зависит от вашего определения ООП.
С этим не поспоришь.
Как сказал keith, тема действительно холиварная.
Как сказал keith, тема действительно холиварная.
А можно поподробнее о вопросах собеседований? Что спрашивали и что слышали / хотели услышать?
На счет того, что anemic менее ООП — это вопрос еще тот )
Какая разница в какой иерархии будет наследование в сущностях домена или в сервисах?
Как измерить степень ООП?
Потом, у самой сущности (ее пропертей) и у ее логики может быть разное время жизненного цикла.
При маппинге в DDD возникает слой с кучей DTO, которые являются дублированием сущностей домена.
Я не против DTO, но только когда сущность покидает границы приложения (или даже команды разработчиков).
Ну и в завершение:
Cohesion wiki
Communicational cohesion — это логика в сущностях домена.
Functional cohesion (best) — это логика в сервисах домена или в репозиториях (слое доступа к данным).
зы не холивара ради, надеюсь на логичную аргументацию.
На счет того, что anemic менее ООП — это вопрос еще тот )
Какая разница в какой иерархии будет наследование в сущностях домена или в сервисах?
Как измерить степень ООП?
Потом, у самой сущности (ее пропертей) и у ее логики может быть разное время жизненного цикла.
При маппинге в DDD возникает слой с кучей DTO, которые являются дублированием сущностей домена.
Я не против DTO, но только когда сущность покидает границы приложения (или даже команды разработчиков).
Ну и в завершение:
Cohesion wiki
Communicational cohesion — это логика в сущностях домена.
Functional cohesion (best) — это логика в сервисах домена или в репозиториях (слое доступа к данным).
зы не холивара ради, надеюсь на логичную аргументацию.
«А можно поподробнее о вопросах собеседований? Что спрашивали и что слышали / хотели услышать?»
Я постараюсь чуть позже об этом написать, в двух словах наверно не выйдет.
Вопросы у вас хорошие :) Собственно, сам факт подобных дискуссий, а они встречаются почти везде, где пишут data vs domain, говорит о том, что тема спорная и нераскрытая и ее следует исследовать.
Попробую ответить.
«Какая разница в какой иерархии будет наследование в сущностях домена или в сервисах?»
В ООП объекты могут обладать не только данными, но и действиями / методами, это известно всем и на этом строится собственно весь ООП (инкапсуляция, наследования и тп)
Поэтому ООП хорошо подходит для моделирования чего-то, что обладает не только данными, но и действиями, а так же поведением.
Когда мы выносим весь функционал из моделей в сервисы, то мы разделяем данные и «действия», ведь в ваших сервисах обычно нет данных, это абстракция поведения. Сервисы не могут менять внутреннее состояние модели.
По сути, если идти дальше, то такие модели можно сделать immutable, да, и это нас приблизит к функциональным паттернам. Это не хорошо и не плохо (если говорить об абстрактном решении), это просто по-другому.
Более того, такая anemic модель может лежать в основе rich модели (т.е. rich модель может быть большой «оберткой» для anemic).
«При маппинге в DDD возникает слой с кучей DTO, которые являются дублированием сущностей домена.»
Да, именно поэтому полноценный ddd получается дорогим для небольших проектов, особенно, если у вас реляционная СУБД
Вообще, DTO тема тоже отдельная. Уровень DTO зависит от сложности модели.
ps кстати, добавлю масла в холивар :) anemic model добавляет в жизнь программиста как минимум две «сущности»: модель и сервис, а domain подход, больше стремится к упаковыванию всего этого в модель, поэтому вам не надо вспоминать какой сервис делает, то что вам нужно
Я постараюсь чуть позже об этом написать, в двух словах наверно не выйдет.
Вопросы у вас хорошие :) Собственно, сам факт подобных дискуссий, а они встречаются почти везде, где пишут data vs domain, говорит о том, что тема спорная и нераскрытая и ее следует исследовать.
Попробую ответить.
«Какая разница в какой иерархии будет наследование в сущностях домена или в сервисах?»
В ООП объекты могут обладать не только данными, но и действиями / методами, это известно всем и на этом строится собственно весь ООП (инкапсуляция, наследования и тп)
Поэтому ООП хорошо подходит для моделирования чего-то, что обладает не только данными, но и действиями, а так же поведением.
Когда мы выносим весь функционал из моделей в сервисы, то мы разделяем данные и «действия», ведь в ваших сервисах обычно нет данных, это абстракция поведения. Сервисы не могут менять внутреннее состояние модели.
По сути, если идти дальше, то такие модели можно сделать immutable, да, и это нас приблизит к функциональным паттернам. Это не хорошо и не плохо (если говорить об абстрактном решении), это просто по-другому.
Более того, такая anemic модель может лежать в основе rich модели (т.е. rich модель может быть большой «оберткой» для anemic).
«При маппинге в DDD возникает слой с кучей DTO, которые являются дублированием сущностей домена.»
Да, именно поэтому полноценный ddd получается дорогим для небольших проектов, особенно, если у вас реляционная СУБД
Вообще, DTO тема тоже отдельная. Уровень DTO зависит от сложности модели.
ps кстати, добавлю масла в холивар :) anemic model добавляет в жизнь программиста как минимум две «сущности»: модель и сервис, а domain подход, больше стремится к упаковыванию всего этого в модель, поэтому вам не надо вспоминать какой сервис делает, то что вам нужно
По-первых, я не говорил, что надо запаковывать всю логику в сервисы, я говорил о тенденциях. В Anemic модели непонятно, что хранится в моделях, а что в сервисах, обычно это связанно с ограничениями уровня персистенции (orm и тп)
Во-вторых, посмею в вам не согласиться, но сервисы не есть доменные объекты. Сервисы могут находиться (и часто находятся) в уровне бизнес логики и работать с сущностями, но доменными объектами они не являются по определению.
Во-вторых, посмею в вам не согласиться, но сервисы не есть доменные объекты. Сервисы могут находиться (и часто находятся) в уровне бизнес логики и работать с сущностями, но доменными объектами они не являются по определению.
В ООП объекты могут обладать не только данными, но и действиями / методами, это известно всем и на этом строится собственно весь ООП (инкапсуляция, наследования и тп)Крайне редко сущности моделируют что-то содержащее поведение — ордер, инвойс, клиент и пр. — это не модели с поведениями, а скорее документы с информацией о реальных ордерах, инвойсах и пр. Документы не содержат своего поведения.
Даже в играх, где, казалось бы, поведение присутствует, его часто выносят в отдельные классы — я специально интересовался на эту тему у игроделов. Человек, конечно, может сам иметь метод «сесть в транспортное средство», но как правило, за эту логику отвечает отдельный сервис, который знает как конкретному человеку содиться в конкретное транспортное средство и задействует для этого несколько модулей, в т.ч. проигрыватель анимации. Конечно, можно в методе Person.SeatInTheTransport() вызывать этот самый сервис, но это не более ООП'шно, на мой взгляд.
Сервисы не могут менять внутреннее состояние модели.Тут под сервисами имелись ввиду репозитории, а они могут менять состояние. Да и сервисам домена (из DDD) ничто не мешает менять состояние сущностей.
Вообще, DTO тема тоже отдельная. Уровень DTO зависит от сложности модели.В вьюхих Вы используете DTO или сущности домена? Потому что DDD'шники любят там DTO, а это автоматически создает почти полную копию домена и чаще даже еще больше сущностей, т.к. одно и тоже надо отображать и так и этак и начинаются PersonWithPhotoDTO, PersonFullDto и пр. Я опять-таки не проив этого если данные передаются по сети на клиента, но даже тут можно не писать DTO, если клиента пишет ваша команда и клиент с серверной частью сильно связаны и не имеют нескольких версий протокола одновременно.
anemic model добавляет в жизнь программиста как минимум две «сущности»: модель и сервис, а domain подход, больше стремится к упаковыванию всего этого в модельтолько Rich DDD взамен плодит целых два упомянутых слоя — Mappings и DTO's.
Очень интересно продолжить поиск истины, а то сколько этим занимаюсь, а все тема открыта ) Понятно, что разница может быть незначительной, т.е. по сути не важно как делать — rich или anemic, но более детально рассмотреть плюсы и минусы всегда полезно )
«Крайне редко сущности моделируют что-то содержащее поведение» — да, согласен, это известная проблема, но она приводит к полной дискредитации самого ООП. Над этим можно размышлять долго, я пока не готов заявить что-то определенное :)
По идее внутреннее состояние менять может только сама модель, ни один сервис, в том числе и репозиторий, не имеет доступа к внутреннему состоянию, а работает только с «интерфейсом» публичных свойств и методов (грубо говоря, сервис не может изменить приватную переменную объекта)
Вообще, довольно интересная тема о состояниях модели в ооп, я размышлял на эту тему, гуглил, но к сожалению не смог найти никаких упоминаний об этом. Можно выделить внутреннее и внешнее состояния моделей, причем множество состояний в общем случае штука не конечная, и основываясь на этом можно попытаться перейти к каким-то другим штукам. Я пробовал изобрести некий мат. аппарат для этого (кстати, когда использовал anemic :) ), но потерпел своего рода фиаско, так как не смог извлечь практической выгоды
«только Rich DDD взамен плодит целых два упомянутых слоя — Mappings и DTO's.»
да, такая проблема есть :)
По идее внутреннее состояние менять может только сама модель, ни один сервис, в том числе и репозиторий, не имеет доступа к внутреннему состоянию, а работает только с «интерфейсом» публичных свойств и методов (грубо говоря, сервис не может изменить приватную переменную объекта)
Вообще, довольно интересная тема о состояниях модели в ооп, я размышлял на эту тему, гуглил, но к сожалению не смог найти никаких упоминаний об этом. Можно выделить внутреннее и внешнее состояния моделей, причем множество состояний в общем случае штука не конечная, и основываясь на этом можно попытаться перейти к каким-то другим штукам. Я пробовал изобрести некий мат. аппарат для этого (кстати, когда использовал anemic :) ), но потерпел своего рода фиаско, так как не смог извлечь практической выгоды
«только Rich DDD взамен плодит целых два упомянутых слоя — Mappings и DTO's.»
да, такая проблема есть :)
По идее внутреннее состояние менять может только сама модель, ни один сервис, в том числе и репозиторий, не имеет доступа к внутреннему состоянию, а работает только с «интерфейсом» публичных свойств и методов (грубо говоря, сервис не может изменить приватную переменную объекта)Имел ввиду свойства. Закрытые переменные, конечно, сервис изменить не сможет, но если сервису это будет нужно, то переменная превратиться в открытое свойство. Не встречал необходимости что-то прятать в anemic'е от сервисов. Может у Вас есть подходящий пример?
«Крайне редко сущности моделируют что-то содержащее поведение» — да, согласен, это известная проблема, но она приводит к полной дискредитации самого ООП.Вопрос, что такое «поведение»? Обычно нет никако
Поведение — это воздействие на состояние.
В случае, если поведение это часть модели, то оно может изменить внутреннее состояние модели (конечно, если такое имеется). Необходимо ли реально внутреннее состояние модели — вопрос отдельный.
В случае сервисов — они могут изменить внутреннее состояние только косвенно, через доступные интерфейсы модели
В случае, если поведение это часть модели, то оно может изменить внутреннее состояние модели (конечно, если такое имеется). Необходимо ли реально внутреннее состояние модели — вопрос отдельный.
В случае сервисов — они могут изменить внутреннее состояние только косвенно, через доступные интерфейсы модели
Поведение — это воздействие на состояние.Ну да, то, что я читал в хелпе к Visual Basic 5.0 в 1998 году. «Классика». Я готов использовать это определение. Остаётся понять, состояние какого из объектов мы меняем, когда заставляем их взаимодействовать. Например, сажаем человека в транспортное средство. Пока либо человек либо транспортное средство — ненужная абстракция, мы можем считать, что меняем состояние только одного объекта (другого из них). Когда не можем один из них считать ненужной абстракцией — anemic object (не буду использовать слишком многозначный термин «модель») так и просится.
Мне кажется подобные попытки создать демо-модель на «людях-транспортах» несколько неудачны по той причине, что они слишком абстрактны и вырваны из контекста.
В реальной ситуации у вас будет еще масса условий, в том числе и не связанных с программированием. И мой подход — это комплексный анализ всех условий.
Ведь в ddd есть еще такие понятия как value-object и aggregate model. Может быть у вас «человек» это value-object? А может и нет. Может быть у вас автобус это aggregate model и содержит человека как часть себя?
В реальной ситуации у вас будет еще масса условий, в том числе и не связанных с программированием. И мой подход — это комплексный анализ всех условий.
Ведь в ddd есть еще такие понятия как value-object и aggregate model. Может быть у вас «человек» это value-object? А может и нет. Может быть у вас автобус это aggregate model и содержит человека как часть себя?
Человек, конечно, может сам иметь метод «сесть в транспортное средство»А почему это не метод транспортного средства «принять в себя человека»? Так вот похоливарят-похоливарят, и вынесут логику в сервисы — чтоб ни тому ни этому.
Наследование (если нельзя поменять предка в рантайме) считается bad style, ибо tight cohesion. Советуют предпочитать ему композицию.
> Как измерить степень ООП?
Простой индикатор: сущности в «правильном» ООП имеют поведение и инкапсулируют данные.
В процедурном стиле же мы имеем immutable слой бизнес-логики (сервисы) — своего рода «конвейер», через который мы гоняем классы-данные (DTO).
Простой индикатор: сущности в «правильном» ООП имеют поведение и инкапсулируют данные.
В процедурном стиле же мы имеем immutable слой бизнес-логики (сервисы) — своего рода «конвейер», через который мы гоняем классы-данные (DTO).
Как пишет Фаулер, шаблоны проектирования имеют свойство вытанцовываться сами собой в процессе неоднократного рефакторинга. Считается, что типа шаблоны проектирования — это хорошо и круто. Если анемичная модель тоже имеет свойство вытанцовываться в результате неоднократного злобного рефакторинга, то не повод ли это считать её тоже чем-то хорошим и крутым?
Кстати, куда относить доменную логику — к модели или к контроллеру — это тоже холиварная тема.
Кстати, куда относить доменную логику — к модели или к контроллеру — это тоже холиварная тема.
Почему-то «data-driven» подход часто считают устаревшим «процедурным». Я считаю что это неверно.
В моем понимании «data-driven» — это уход от ООП в ФП-сторону. Данные отдельно, функции отдельно. Данные по-возможности immutable, функции — по-возможности чистые.
Такой ФП-стиль подходит для очень большого класса приложений. Большая часть enterprise-логики, например, на это очень хорошо ложится. Очень важно понимать что сам по себе этот подход ни к какому бардаку не приводит. Более того, мой опыт говорит что этот подход очень часто сильно лучше классического ООП.
Между тем есть области где ФП требует сильно и заморочено абстрагироваться, а ООП позволяет делать просто и понятно. Яркий пример — UI. И вот там пока цветет классический ООП, и это наверное наиболее прагматичное решение на данный момент. Хотя FRP в виде всяких продвинутых data-binding-ов и тут подступает.
В моем понимании «data-driven» — это уход от ООП в ФП-сторону. Данные отдельно, функции отдельно. Данные по-возможности immutable, функции — по-возможности чистые.
Такой ФП-стиль подходит для очень большого класса приложений. Большая часть enterprise-логики, например, на это очень хорошо ложится. Очень важно понимать что сам по себе этот подход ни к какому бардаку не приводит. Более того, мой опыт говорит что этот подход очень часто сильно лучше классического ООП.
Между тем есть области где ФП требует сильно и заморочено абстрагироваться, а ООП позволяет делать просто и понятно. Яркий пример — UI. И вот там пока цветет классический ООП, и это наверное наиболее прагматичное решение на данный момент. Хотя FRP в виде всяких продвинутых data-binding-ов и тут подступает.
Кажется, налицо непонимание того, что такое data-driven design.
Впрочем, я и сам затруднился бы дать определение.
Впрочем, я и сам затруднился бы дать определение.
Согласен и с вами, собственно, как вы уже сказали выше data driven и domain driven понятие вне ООП и ФП.
Единственное, имхо, на практике картина другая
Единственное, имхо, на практике картина другая
В ООП вообще очень плохо с точными определениями и терминологией. Очень оно с гуманитарной стороны заходит.
Скажу так: под современным data-driven я понимаю систему из «голых» DTO-классов почти без методов, и набора сервисов с логикой. На DTO-классы сверху декларативно навешивается сериализация, мэппинг на базу, всякая валидация и т.п. Сервисы же неплохо структурируются и управляются каким-нибудь dependency-injection-фреймворком.
Некоторые воспринимают это как процедурное программирование на стероидах. Я вижу в этом уход в ФП и декларативное программирование.
Скажу так: под современным data-driven я понимаю систему из «голых» DTO-классов почти без методов, и набора сервисов с логикой. На DTO-классы сверху декларативно навешивается сериализация, мэппинг на базу, всякая валидация и т.п. Сервисы же неплохо структурируются и управляются каким-нибудь dependency-injection-фреймворком.
Некоторые воспринимают это как процедурное программирование на стероидах. Я вижу в этом уход в ФП и декларативное программирование.
Насколько я знаю, это на сегодня мейнстрим до степени капитанства и боянизма.
Я про второй абзац.
под современным data-driven я понимаю систему из «голых» DTO-классов почти без методов, и набора сервисов с логикой.
Вот только при чем тут data-driven, если это прекрасно вписывается, например, в SOA?
Ну и да, с автором-то вы не совпадаете в определениях.
А чем принципиально SOA отличается от anemic, data-driven и других еще модных терминов?
Про это больше одной книжки написано.
Если совсем вкратце — то автономностью, интероперабильностью и стандартами.
Если совсем вкратце — то автономностью, интероперабильностью и стандартами.
Читал я эти книжки. Мое отношение к ним — это что-то между гуманитарщиной и откровенным лохотроном с псевдонаукой. В гуманитарных науках стараются хотя-бы определения терминам давать. Этот весь булщит помогает продавать и впаривать, а с практической точки зрения оно только запутывает и уводит от сути.
Мне прямо стало любопытно, какие именно книжки вы читали.
Но вообще, конечно, меня забавляет ваше отношение к гуманитарным наукам.
Но вообще, конечно, меня забавляет ваше отношение к гуманитарным наукам.
А всю эту бурду классическую — Буча, Фаулера, GoF, всякие Domain-Driven Design и т.п.
Ну понятно. В этом списке ни одной книги про SOA нет, если что.
Я не понимаю зачем писать целую книжку про SOA, и с какой стороны SOA вообще прилетело в тему разговора.
Я не понимаю зачем писать целую книжку про SOA
… и даже не одну. Видимо, потому, что есть много всякого интересного в этой области.
с какой стороны SOA вообще прилетело в тему разговора.
Ну так вы тред-то перечитайте:
Вот только при чем тут data-driven, если это [система из «голых» DTO-классов почти без методов, и набора сервисов с логикой] прекрасно вписывается, например, в SOA?
Я примерно 5 лет на работе вижу SOA-системы. В свое время очень модно было, вот и наплодили. Иногда в тему, но в основном — жуткая инертность на изменения и дикие проблемы с производительностью и доступностью.
>Вот только при чем тут data-driven, если это [система из «голых» DTO-классов почти без методов, и набора сервисов с логикой] прекрасно вписывается, например, в SOA?
Звучит как «причем тут сахар, если мед сладкий?»
>Вот только при чем тут data-driven, если это [система из «голых» DTO-классов почти без методов, и набора сервисов с логикой] прекрасно вписывается, например, в SOA?
Звучит как «причем тут сахар, если мед сладкий?»
Иногда в тему, но в основном — жуткая инертность на изменения и дикие проблемы с производительностью и доступностью.
Я эту фразу слышу про практически любой подход.
Звучит как «причем тут сахар, если мед сладкий?»
Почти. Точнее было бы сказать «почему вы определяете сахар как „что-то сладкое“, когда есть еще и мед»?
Причём здесь SOA, основной отличительной чертой которой является взаимодействие компонентов через web? Тут термин «сервисы» взят в полужаргонном значении из современной архитектуры Java-web-ORM-приложения: сервлет-контроллер-сервис-DAO-Entity.
Ну а то, что data-driven вписывается в SOA, это не повод приплетать сюда web-взаимодействие.
Ну а то, что data-driven вписывается в SOA, это не повод приплетать сюда web-взаимодействие.
Согласен с вами.
Близость того, о чем вы говорите (хотя это не совсем data-driven), к ФП меня всегда интересовала и интриговала. К сожалению, мой опыт в ФП не настолько хорош, чтоб я мог выдвигать какие-то теоретические гипотезы, поэтому я не стал упоминать об этом.
Близость того, о чем вы говорите (хотя это не совсем data-driven), к ФП меня всегда интересовала и интриговала. К сожалению, мой опыт в ФП не настолько хорош, чтоб я мог выдвигать какие-то теоретические гипотезы, поэтому я не стал упоминать об этом.
Пишите код бля, теоретики.
да, думать намного, намного интересней, чем писать код
За думать денег не платят. Нужно думать и кодить одновременно.
Как -то пункты «Ориентация на действия» и «Ориентация на интерфейс» у автора оказались проработаны слабо, и «Event Driven Programming» отнесено к обоим пунктам. Наверное потому, что в IRL они редко встречаются…
Были бы в языке trait-ы — вопрос бы куда в Data Driven-случае всунуть getMaximalPricedProduct() не стоял бы… А так — имеем оверхед в виде лишнего интерфейса и реализации паттерна «визитор»…
Последняя фраза очень точная, есть только две парадигмы: помогающая решить задачу и мешающая решению оной.
В контексте сложности хранения данных с Domain-driven design. Является ли OODMS решением? Что вы думаете о состоянии OODMS рынка на данный момент?
К сожалению, реального практического опыта с OODMS пока нет. Из нереляционных СУБД мы используем MongoDb (с .net'ом потому что у него есть linq адаптер, и как показала практика переехать с mssql на mongo вышло не так уж и сложно, за счет абстракций уровня данных, но тем не менее основной субд является mssql по ряду других практических причин). Раньше использовали CouchBase (в основном в связке с проектами где много javascript'а).
Вот, и хотя Mongo не является OODMS, но она позволяет сохранять скимлесс-документы и, да, это порой может реально упростить меппинг моделей (ну т.е. тут и меппать ничего не надо).
Могу предположить, что в OODMS все может быть еще круче и удобней и в один прекрасный день мы начнем использовать такой типа субд :)
Вот, и хотя Mongo не является OODMS, но она позволяет сохранять скимлесс-документы и, да, это порой может реально упростить меппинг моделей (ну т.е. тут и меппать ничего не надо).
Могу предположить, что в OODMS все может быть еще круче и удобней и в один прекрасный день мы начнем использовать такой типа субд :)
Второй вариант все же не подходит для большинства программ, по причине неотказаустойчивости. И если использоваить минимум возможностей субд, то придется писать много лишнего кода в BL или где там еще. Зачем изобретать велосипед? Если уже не пользоватся ORM, которая будучи абстракцией над БД усложняющей прямой доступ к ней, то разумно пользоваться плюсом отсутствия ORM — прямым доступом ко все богатствам БД.
У вас DataDriven «вырождается» в то, что называется DCI. Он фактически строится вокруг идеи анемичной модели. Далее, как я понимаю, всякие методы вида «получи то-то» отправляются в роли (ведь правда же для роли Customer совершенно не важен метод getAvatar), а взаимодействия описываются отдельными классами в терминах ролей.
Сам пока не пробовал эту модель, но звучит очень разумно, не как антипаттерн, а вполне себе как парадигма программирования (довольно модная нынче). Одна проблема, что в чистом виде реализовать это можно не в любом языке, но это вопрос не к парадигме, а к языку.
Сам пока не пробовал эту модель, но звучит очень разумно, не как антипаттерн, а вполне себе как парадигма программирования (довольно модная нынче). Одна проблема, что в чистом виде реализовать это можно не в любом языке, но это вопрос не к парадигме, а к языку.
Проходит время, и нам требуется добавить дополнительную логику в программу — например, находить у ордера товар с самой высокой ценой. Здесь уже могут возникнуть проблемы, если ваша orm не поддерживает внешние связи (т.е. сущностные классы ничего не знаю о контексте данных), в этом случае, придется создавать сервис, в котором будет метод — по ордеру вернуть нужный продукт. Но, наша orm хорошая, умеет работать с внешними связями, и мы просто добавляем метод в класс ордера. Снова радуемся жизни, цель достигнута, в класс добавлен метод, у нас почти настоящее ООП.
Это и на два абзаца ниже.
Во-первых, что значит «внешние связи»? Как это связано с поиском товара?
Во-вторых, это не DDD. В методологии явно указано, как нужно поступать в таких случаях. И это совсем не «добавляем метод». Так что одинаковых методов в итоге бы не было, и рефакторинга бы не было, и анемичной модели бы не было.
1. Мне кажется пример проблемы с orm довольно очевиден, возможно вы не так поняли, что я пытался сказать в посте. Ок, внешняя связь — в общем случае, это абстракция связи между двумя сущностями. В контексте рел. субд это например внешние ключи. Большинство современных ORM отлично обрабатывают внешние ключи и переносят абстракцию в сгенерированные сущностные классы, поэтому пример проблемы на самом деле больше надуман, чтоб показать суть. Если более конкретно, то например, из моделей сгенерированных через linq2sql ( sqlmetal ) нельзя получить контекст, и, если представить, что sqlmetal не умел бы обрабатывать внешние ключи (или ключа бы просто не было), то вместо такого «order.Products» вообще у сущности ордера ничего не было б, поэтому из сущностного класса получить сведение о связанных продуктах не получилось б.
2. Естественно это не ddd. Как бы об этом потом и говорится.
Интересно было б услышать Ваш вариант реализации описанной задачи в методологии DDD
2. Естественно это не ddd. Как бы об этом потом и говорится.
Интересно было б услышать Ваш вариант реализации описанной задачи в методологии DDD
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Парадигмы программирования. Data Driven vs Domain Driven