Да, вы правы, в моей практике мы разрабатываем ПО, в котором «Ориентация на действия» и «Ориентация на интерфейс» не являются особо выраженными направлениями. Т.е. обычно с этим все довольно ясно и вопросов не вызывает
«Крайне редко сущности моделируют что-то содержащее поведение» — да, согласен, это известная проблема, но она приводит к полной дискредитации самого ООП. Над этим можно размышлять долго, я пока не готов заявить что-то определенное :)
По идее внутреннее состояние менять может только сама модель, ни один сервис, в том числе и репозиторий, не имеет доступа к внутреннему состоянию, а работает только с «интерфейсом» публичных свойств и методов (грубо говоря, сервис не может изменить приватную переменную объекта)
Вообще, довольно интересная тема о состояниях модели в ооп, я размышлял на эту тему, гуглил, но к сожалению не смог найти никаких упоминаний об этом. Можно выделить внутреннее и внешнее состояния моделей, причем множество состояний в общем случае штука не конечная, и основываясь на этом можно попытаться перейти к каким-то другим штукам. Я пробовал изобрести некий мат. аппарат для этого (кстати, когда использовал anemic :) ), но потерпел своего рода фиаско, так как не смог извлечь практической выгоды
«только Rich DDD взамен плодит целых два упомянутых слоя — Mappings и DTO's.»
да, такая проблема есть :)
По-первых, я не говорил, что надо запаковывать всю логику в сервисы, я говорил о тенденциях. В Anemic модели непонятно, что хранится в моделях, а что в сервисах, обычно это связанно с ограничениями уровня персистенции (orm и тп)
Во-вторых, посмею в вам не согласиться, но сервисы не есть доменные объекты. Сервисы могут находиться (и часто находятся) в уровне бизнес логики и работать с сущностями, но доменными объектами они не являются по определению.
Согласен и с вами, собственно, как вы уже сказали выше data driven и domain driven понятие вне ООП и ФП.
Единственное, имхо, на практике картина другая
Согласен с вами.
Близость того, о чем вы говорите (хотя это не совсем data-driven), к ФП меня всегда интересовала и интриговала. К сожалению, мой опыт в ФП не настолько хорош, чтоб я мог выдвигать какие-то теоретические гипотезы, поэтому я не стал упоминать об этом.
«А можно поподробнее о вопросах собеседований? Что спрашивали и что слышали / хотели услышать?»
Я постараюсь чуть позже об этом написать, в двух словах наверно не выйдет.
Вопросы у вас хорошие :) Собственно, сам факт подобных дискуссий, а они встречаются почти везде, где пишут data vs domain, говорит о том, что тема спорная и нераскрытая и ее следует исследовать.
Попробую ответить.
«Какая разница в какой иерархии будет наследование в сущностях домена или в сервисах?»
В ООП объекты могут обладать не только данными, но и действиями / методами, это известно всем и на этом строится собственно весь ООП (инкапсуляция, наследования и тп)
Поэтому ООП хорошо подходит для моделирования чего-то, что обладает не только данными, но и действиями, а так же поведением.
Когда мы выносим весь функционал из моделей в сервисы, то мы разделяем данные и «действия», ведь в ваших сервисах обычно нет данных, это абстракция поведения. Сервисы не могут менять внутреннее состояние модели.
По сути, если идти дальше, то такие модели можно сделать immutable, да, и это нас приблизит к функциональным паттернам. Это не хорошо и не плохо (если говорить об абстрактном решении), это просто по-другому.
Более того, такая anemic модель может лежать в основе rich модели (т.е. rich модель может быть большой «оберткой» для anemic).
«При маппинге в DDD возникает слой с кучей DTO, которые являются дублированием сущностей домена.»
Да, именно поэтому полноценный ddd получается дорогим для небольших проектов, особенно, если у вас реляционная СУБД
Вообще, DTO тема тоже отдельная. Уровень DTO зависит от сложности модели.
ps кстати, добавлю масла в холивар :) anemic model добавляет в жизнь программиста как минимум две «сущности»: модель и сервис, а domain подход, больше стремится к упаковыванию всего этого в модель, поэтому вам не надо вспоминать какой сервис делает, то что вам нужно
Data и domain — это просто два разных подхода, которые удобно использовать каждый в своей ситуации. На практике же, если говорить о «бизнес» приложениях, часто ситуации бывают неоднозначные, вот, ну, и собственно, системный архитектор как раз и должен решать эти проблемы.
Отвечая на ваш вопрос — я не могу сказать, как data или domain влияет на остальное приложение, так как это очень абстрактный вопрос, имхо. Мерой влияния может быть сложность перехода от data к domain и обратно
«Подскажите, пожалуйста, примеры open source приложений с Rich Domain» — не подскажу, ибо сам таких не знаю. Мне кажется «чистый» DDD найти можно только в надуманным примерах.
Проблема анемичной модели в том, что она уходит от ООП. Поэтому если вы программируете в стиле ООП, анемичная модель просто будет инородной деталькой. Хорошо это или плохо — тема холиварная, я довольно много изучал этот вопрос и сталкивался с обилием споров, и у всех есть аргументы :)
Имхо, если разработчик знает суть ddd и dbdd и других «dd», то он осознано может уйти и в анемичную модель, и все у него будет хорошо, но проблема то в том, что многие программисты знают, что такое orm и как нагенерить классов, а вот, что потом с этим делать не знают (или думают, что знают :)
Заявляю это на основании проведенных собеседований.
В целом с вами безусловно согласен, но на практике случается, что Data driven с ООП плохо дружат, хоть и с этим вполне можно жить. Статья от части об этом.
По идее внутреннее состояние менять может только сама модель, ни один сервис, в том числе и репозиторий, не имеет доступа к внутреннему состоянию, а работает только с «интерфейсом» публичных свойств и методов (грубо говоря, сервис не может изменить приватную переменную объекта)
Вообще, довольно интересная тема о состояниях модели в ооп, я размышлял на эту тему, гуглил, но к сожалению не смог найти никаких упоминаний об этом. Можно выделить внутреннее и внешнее состояния моделей, причем множество состояний в общем случае штука не конечная, и основываясь на этом можно попытаться перейти к каким-то другим штукам. Я пробовал изобрести некий мат. аппарат для этого (кстати, когда использовал anemic :) ), но потерпел своего рода фиаско, так как не смог извлечь практической выгоды
«только Rich DDD взамен плодит целых два упомянутых слоя — Mappings и DTO's.»
да, такая проблема есть :)
Во-вторых, посмею в вам не согласиться, но сервисы не есть доменные объекты. Сервисы могут находиться (и часто находятся) в уровне бизнес логики и работать с сущностями, но доменными объектами они не являются по определению.
Единственное, имхо, на практике картина другая
Близость того, о чем вы говорите (хотя это не совсем data-driven), к ФП меня всегда интересовала и интриговала. К сожалению, мой опыт в ФП не настолько хорош, чтоб я мог выдвигать какие-то теоретические гипотезы, поэтому я не стал упоминать об этом.
Я постараюсь чуть позже об этом написать, в двух словах наверно не выйдет.
Вопросы у вас хорошие :) Собственно, сам факт подобных дискуссий, а они встречаются почти везде, где пишут data vs domain, говорит о том, что тема спорная и нераскрытая и ее следует исследовать.
Попробую ответить.
«Какая разница в какой иерархии будет наследование в сущностях домена или в сервисах?»
В ООП объекты могут обладать не только данными, но и действиями / методами, это известно всем и на этом строится собственно весь ООП (инкапсуляция, наследования и тп)
Поэтому ООП хорошо подходит для моделирования чего-то, что обладает не только данными, но и действиями, а так же поведением.
Когда мы выносим весь функционал из моделей в сервисы, то мы разделяем данные и «действия», ведь в ваших сервисах обычно нет данных, это абстракция поведения. Сервисы не могут менять внутреннее состояние модели.
По сути, если идти дальше, то такие модели можно сделать immutable, да, и это нас приблизит к функциональным паттернам. Это не хорошо и не плохо (если говорить об абстрактном решении), это просто по-другому.
Более того, такая anemic модель может лежать в основе rich модели (т.е. rich модель может быть большой «оберткой» для anemic).
«При маппинге в DDD возникает слой с кучей DTO, которые являются дублированием сущностей домена.»
Да, именно поэтому полноценный ddd получается дорогим для небольших проектов, особенно, если у вас реляционная СУБД
Вообще, DTO тема тоже отдельная. Уровень DTO зависит от сложности модели.
ps кстати, добавлю масла в холивар :) anemic model добавляет в жизнь программиста как минимум две «сущности»: модель и сервис, а domain подход, больше стремится к упаковыванию всего этого в модель, поэтому вам не надо вспоминать какой сервис делает, то что вам нужно
Отвечая на ваш вопрос — я не могу сказать, как data или domain влияет на остальное приложение, так как это очень абстрактный вопрос, имхо. Мерой влияния может быть сложность перехода от data к domain и обратно
Как сказал keith, тема действительно холиварная.
Проблема анемичной модели в том, что она уходит от ООП. Поэтому если вы программируете в стиле ООП, анемичная модель просто будет инородной деталькой. Хорошо это или плохо — тема холиварная, я довольно много изучал этот вопрос и сталкивался с обилием споров, и у всех есть аргументы :)
Имхо, если разработчик знает суть ddd и dbdd и других «dd», то он осознано может уйти и в анемичную модель, и все у него будет хорошо, но проблема то в том, что многие программисты знают, что такое orm и как нагенерить классов, а вот, что потом с этим делать не знают (или думают, что знают :)
Заявляю это на основании проведенных собеседований.