Приведенный мною пример подходит только для одного типа приложения.
Для передачи данных между разными частями представления на клиенте конечно могут применяться события, но к событиям в бизнес-логике на сервере это не имеет отношения. В двухзвенном приложении все то же самое, просто там часть приложения играет роль сервера. Возможно, вы просто считаете избыточным создавать объект Ventilator, когда у вас уже есть объект VentilatorView и передаете его в логику, которая на самом деле должна принимать Ventilator, но это неправильно. Например, код сохранения параметров вентилятора в файл или базу должен работать только с объектом Ventilator, но не VentilatorView. Представьте, что любые кнопки на форме просто отправляют данные в другой процесс, который запущен без окна, и все расчеты и сохранение данных находятся там. Если там будет какое-то взаимодействие этих сущностей, то его можно сделать событиями.
как агрегаты могут взаимодействовать при помощи доменных событий
Вопрос "как" описан в данной статье - создаем событие, отправляем в главный обработчик, он вызывает конкретный обработчик, он вызывает метод другой сущности. На вопрос "зачем" я ответил выше - обновить поле "customer.order_count" при создании заказа без использования сервиса, который работает одновременно с 2 агрегатами Order и Customer. Но повторюсь, я считаю, что правильнее сделать сервис.
Нет, любая бизнес-логика и конкретно доменные события никак не связаны с типом приложения. Бизнес-логика с сущностями может быть в любом приложении. В трехзвенном приложении бизнес-логика работает на сервере и про события между формами на клиенте ничего не знает. Если приведете конкретные примеры расчетов, попробую объяснить подробнее.
Из описания непонятно, какие это могут быть агрегаты и расчеты, и насколько правильно делать для них именно так, но логика совершенно точно никак не должна быть связана с формами. Может они есть, может их нет, логика взаимодействия сущностей от этого не меняется. Представьте, что у вас вместо формы браузер, форма работает на клиенте, а логика на сервере.
Например, надо сохранить использованный в заказе метод оплаты для следующих покупок. Метод оплаты может быть отдельной сущностью или частью агрегата Customer. Или в Customer есть денормализованное поле для количества заказов, и его надо обновить. Это больше связано с принципом DDD "Поля сущности надо менять только из ее методов" и "Один агрегат не может напрямую вызывать методы другого агрегата", чем с реальной необходимостью использовать события. Но код для приема события находится не в сущности, а в отдельном обработчике, который вызывает метод сущности.
На форме располагаются несколько панелей с данными. объекты view model могут участвовать в обмене событиями, если в одной из панелей происходит изменение данных.
Так тут нет никакой бизнес-логики, это исключительно работа представления. Вы поменяли данные, но никуда не сохранили. Если это веб-интерфейс, то пользователь может обновить страницу, и все изменения пропадут. В десктопном приложении он может закрыть окно.
То есть в какой-то момент вам надо будет сохранить данные, чтобы изменения не пропали. В этот момент и начинается бизнес-логика. Она обычно работает на сервере, там нет вью-моделей. Загружается сущность по id, проверяется ее наличие, права доступа, новые данные загружаются в сущность, потом происходит сохранение. И вот тут иногда надо уведомить другие компоненты приложения. Например, сохранить какую-нибудь статистику. Тут могут быть любые действия, которые надо сделать после сохранения.
Большого смысла делать это событиями нет. Если есть контроль над кодом с бизнес-логикой, то лучше написать все вызовы явно. Чтобы программисту не надо было искать по всему приложению, если бизнес скажет "У нас там при таких-то условиях статистика не обновляется".
Но иногда нет желания или возможности менять код, в котором вызывается сохранение сущности. Например, иногда новую функциональность добавляют плагинами, которые реагируют на событие, а основной движок разрабатывает другая команда или сторонняя компания. Или считают, что модификация кода противоречит SOLID, хотя это не так, и намеренно усложняют поддержку приложения.
Ну и что, анализ информации все равно нужен. Кто догадался использовать камень для выкапывания корней, тот будет лучше питаться.
Или Вы про капуцинов?
Про любые виды. Вышли из леса, хоть в саванну, хоть в город, значит попали в новые условия. Приспособление к новым условиям требует анализа информации. Кто лучше анализирует, тот лучше приспособился. Иногда это имеет меньшее влияние. чем сила, тогда эволюционное развитие будет идти медленнее. Но все равно будет, потому что иногда будут появляться сильные и умные особи.
Было бы достаточно - разумные приматы возникли бы в лесу.
Необязательно, что они должны были возникнуть именно к текущему моменту. Может им просто времени нужно было больше, причин же меньше. Австралопитеки появились 4.2 млн лет назад и 1.4 млн лет жили в саванне, прежде чем появились первые Homo. Если в лесу умные обезьяны получают не такое большое эволюционное преимущество, как в саванне, и эволюционируют например в 3 раза медленнее, то сейчас они находятся только на уровне первых Homo. Мы примерно это и наблюдаем - базовые жесты, базовое использование орудий труда, использование лечебных трав. А речь у Homo появилась только через 800 тысяч лет.
А перенаселения у них пока не наблюдается.
Ну то есть если будет переселение, они могут выйти в саванну, и экологическая ниша человека тут ни при чем, потому что люди в саванне не живут. О чем и речь.
Перенаселение наблюдается, я же не просто так сказал про вырубку лесов.
Бабуины? Они и так в саванне живут.
Разные виды, поищите новости про обезьян и города. Те, которые живут не в лесу, очевидно, не будут заходить в города из-за вырубки лесов.
Ну то есть уже есть обезьяны, которые вышли в саванну. Почему вы решили, что через миллион лет они не станут умнее? Бабуины появились 2 млн лет назад, то есть позже австралопитеков. И хоть 1.4 млн лет с того времени уже прошло, нет такого закона природы, что это должно занимать именно 1.4 млн. Может быть 2 или 3.
Чтобы человекообразные обезьяны выходили - что-то не слышно.
А почему надо чтобы выходили именно человекообразные?
Ок, а как это связано с утверждением про экологическую нишу? Кто-то мешает обезьянам выйти из леса в саванну?
И как это означает, что причин становиться умнее в лесу недостаточно? Их может быть меньше, но они есть. У диких обезьян уже есть некоторые общепринятые жесты для коммуникации, они используют лечебные травы и орудия труда.
Более того, из-за вырубки лесов или в поисках пищи многие дикие обезьяны заходят в города, где им надо взаимодействовать с незнакомыми предметами.
Не увидел в Вашем ответе информации по существу вопроса.
Я уже объяснил почему - у вас недостаточно знаний, и вы не хотите их получать.
Вопрос в том как это разделение происходило постепенно-эволюционно миллионы лет
Там написано как. Разделение на разные половые клетки есть даже у одноклеточных. Откройте ссылку и прочитайте. Также поищите, что такое мейоз.
В связи с этим интересен и вопрос о том как появились гаметы - в результате какой-то одной случайной мутации?
Там написано как.
Возможно, Вы это имели в виду когда писали о том что достаточно всего двух согласованных особей.
Не знаю, что вы имеете в виду, но я точно не имел в виду, что что-то появилось сразу.
Либо все это сформировалось путем последовательных микроскопических изменений, не дающих в отдельности никаких очевидных эволюционных преимуществ.
С чего вы взяли, что не дающих в отдельности никаких эволюционных преимуществ? Потому что вам так хочется? Потому что лично вы не понимаете, какие были преимущества?
но все равно почему-то идущих в правильном направлении
Вам уже много раз разные люди объяснили почему - потому что они давали эволюционные преимущества, либо как минимум не мешали. Не было никакого одного правильного направления, было много разных направлений, 90% направлений не получили эволюционные преимущества и исчезли, остались только 10%, от них и появились потомки. И с потомками так же.
Но боюсь что Теория возникновения видов не заморачивается на такие мелочи.
То есть вы не способны взять и проверить в интернете, заморачивается она или нет? Или не хотите проверять, потому что опасаетесь, что узнаете информацию, которая изменит вашу точку зрения?
Интересен был бы также ответ на вопрос о том, как постепенно-эволюционно появились хромосомы.
Ищите в интернете. Прочитайте статьи на Википедии про ДНК и хромосомы. Были бактерии с одной копией ДНК, у некоторых бактерий она иногда билась на части под воздействием разных факторов. Большинство таких бактерий погибло, а некоторые остались. Потом у некоторых иногда к этим отдельным частям ДНК прикреплялись разные белки, большинство таких бактерий погибло, а некоторые остались.
Или это происходило последовательно-эволюционно
Давайте я вам сразу дам ответы на все эти вопросы. По теории эволюции всё, что сейчас стабильно существует и воспроизводится, происходило последовательно-эволюционно. Вообще всё. Этому найдено много подтверждений.
то есть у какого-то промежуточного переходного вида у самки мешочек с икрой вдруг ни с того ни с сего превратился в утробу
"Последовательно-эволюционно" противоречит утверждению "ни с того ни с сего".
Потом через миллион лет что-то подходящее вдруг почему-то появилось у самца. Потом они додумались что с этим всем можно делать и самка научилась вынашивать мальков.
По теории эволюции это не является описанием последовательного эволюционного процесса. А является полной чушью. И так как вы намеренно ее написали, проигнорировав все объяснения, то это означает, что вы не хотите слушать собеседников, не хотите думать, и не хотите узнать нормальные ответы на свои вопросы.
Произошел ли переход от внешнего оплодотворения рыб к внутреннему оплодотворению птиц
У рыб, представьте себе, тоже есть внутреннее оплодотворение. И даже живорождение. И даже одна рыба может быть поочередно самцом и самкой. И даже некоторые способны к самооплодотворению.
С другой стороны, жгутик без фотодиода со всеми каналами, который толкает организм в случайном направлении, также имеет мало смысла.
Еще раз говорю, вы неправильно представляете, как происходят эти процессы. Видимо в силу недостатка знаний. И даже подумать не хотите. Поэтому вам кажется, что имеет мало смысла.
Смысла в случайном передвижении просто дофига. Потому что на другом месте еще есть еда, а на текущем уже нет.
без которой даже фотодиод со всеми нужными каналами не дает никакого эволюционного преимущества.
То есть вы даже про фотосинтез не знаете? Фотодиод у водорослей дает прямое поглощение солнечной энергии, даже без всяких жгутиков.
Любая же из них по-отдельности, созданная случайной мутацией, бессмысленна.
Неправильно. Есть и одноклеточные организмы со жгутиками без реакции на свет (хемосинтезирующие бактерии), и одноклеточные с реакцией на свет без жгутиков (хлорелла).
потому что недоделанный нежизнеспособен
"Без жгутиков" не означает "недоделанный", так же как и "без фотосинтеза" не означает "недоделанный". Они просто разные.
Примеры, которые я привел выше, говорят о том, что ваши представления о мире неверны. Предлагаю вам подумать о том, что вы не учитываете, раз ваши выводы не соответствуют известным фактам.
По второй ссылке написано, почему разделение на 2 пола лучше, чем 1.
оставаясь при этих мутациях согласованными
А почему вы решили, что они оставались согласованными? Те, кто были не согласованными, не оставили потомства. Поэтому в следующих поколениях остались только те, кто были согласованными. И таких поколений было много. Теоретически даже всего двух согласованных особей достаточно, чтобы создать достаточное количество согласованных между собой потомков для поддержания нового вида.
Для более подробных ответов на детские вопросы читайте школьные учебники. Они специально для детей и написаны. Потом у вас будет достаточно знаний, чтобы искать и понимать нужную информацию в более серьезных источниках.
"Фотодиод со всеми нужными каналами" это в простейшем случае 2 клетки - приемник света и триггер мышцы или жгутика. Например, гидра. Даже некоторые одноклеточные умеют реагировать на свет.
каждая из которых по-отдельности не дает никакого эволюционного премущества?
С чего вы взяли, что жгутики не дают эволюционного преимущества?
Но ведь отдельные фотодиоды не дают организму ВООБЩЕ НИЧЕГО! Даже один фотодиод должен иметь канал, по которому сигнал от него будет поступать в мозг!
В статье и не говорится про отдельный фотодиод без канала. Там подразумевается фотодиод со всеми нужными каналами. Для анализа информации не требуется именно мозг, там же рядом в статье фотография моллюска.
А мозг должен отличать сигнал фотодиода от других, например от сигнала прикосновения.
Он и отличает. От фотодиодов сигнал приходит по одним нейронам, с диодов прикосновения по другим.
И должен понимать как на этот конкретный сигнал можно или нужно реагировать.
Он и понимает. В простом случае реакция нейрона сразу связана с действием, в сложном в середине есть дополнительная обработка.
Так что с последовательными изменениями есть большие проблемы.
Проблемы есть только в ваших представлениях о том, как это работает. Вы это представляете неправильно.
Экологическая ниша тут ни при чем, у обезьян в лесу причины становиться умнее никуда не исчезают от того, что люди в 20 километрах от них построили город.
Если вы под бизнес-логикой понимаете что-то другое, то у вас и будет не DDD, а какой-то свой подход.
Правила валидации сущностей чаще всего одни на всех - это же инвариант самой сущности.
Допустим, у какой-то сущности есть статус "На модерации". В это время пользователь не может ее редактировать. При попытке изменить любые данные API должно возвращать ошибку "Сущность находится на модерации" (допустим у нас сложный агрегат, и есть разные методы редактирования). Но прохождение модерации означает изменение статуса, а это тоже редактирование, но его делать можно. При этом самому пользователю не должно быть разрешено менять этот статус. Тут нужные проверки зависят от действия.
Потому что нужно отправить данные созданной сущности в другую систему.
У меня тут потерялось слово "иногда". Но согласен, так будет работать, я сначала неправильно понял вашу мысль.
Да, пока что универсального подхода, который был бы хорош во всем, к сожалению, не придумали.
Логика в сервисах это вполне нормальное решение. Оно универсально, его можно использовать даже если у вас не сущности с базой данных, а стороннее API с названиями процедур, которое хранит данные на своей стороне. Все недостатки, которые можно найти у логики в сервисах, есть и у логики в сущностях, просто немного в другом виде. Только не все это замечают. У меня есть статья на эту тему с примерами кода, посмотрите если интересно.
Для передачи данных между разными частями представления на клиенте конечно могут применяться события, но к событиям в бизнес-логике на сервере это не имеет отношения. В двухзвенном приложении все то же самое, просто там часть приложения играет роль сервера. Возможно, вы просто считаете избыточным создавать объект Ventilator, когда у вас уже есть объект VentilatorView и передаете его в логику, которая на самом деле должна принимать Ventilator, но это неправильно. Например, код сохранения параметров вентилятора в файл или базу должен работать только с объектом Ventilator, но не VentilatorView. Представьте, что любые кнопки на форме просто отправляют данные в другой процесс, который запущен без окна, и все расчеты и сохранение данных находятся там. Если там будет какое-то взаимодействие этих сущностей, то его можно сделать событиями.
Вопрос "как" описан в данной статье - создаем событие, отправляем в главный обработчик, он вызывает конкретный обработчик, он вызывает метод другой сущности. На вопрос "зачем" я ответил выше - обновить поле "customer.order_count" при создании заказа без использования сервиса, который работает одновременно с 2 агрегатами Order и Customer. Но повторюсь, я считаю, что правильнее сделать сервис.
Нет, любая бизнес-логика и конкретно доменные события никак не связаны с типом приложения. Бизнес-логика с сущностями может быть в любом приложении. В трехзвенном приложении бизнес-логика работает на сервере и про события между формами на клиенте ничего не знает. Если приведете конкретные примеры расчетов, попробую объяснить подробнее.
del
Из описания непонятно, какие это могут быть агрегаты и расчеты, и насколько правильно делать для них именно так, но логика совершенно точно никак не должна быть связана с формами. Может они есть, может их нет, логика взаимодействия сущностей от этого не меняется. Представьте, что у вас вместо формы браузер, форма работает на клиенте, а логика на сервере.
Например, надо сохранить использованный в заказе метод оплаты для следующих покупок. Метод оплаты может быть отдельной сущностью или частью агрегата Customer. Или в Customer есть денормализованное поле для количества заказов, и его надо обновить. Это больше связано с принципом DDD "Поля сущности надо менять только из ее методов" и "Один агрегат не может напрямую вызывать методы другого агрегата", чем с реальной необходимостью использовать события. Но код для приема события находится не в сущности, а в отдельном обработчике, который вызывает метод сущности.
Так тут нет никакой бизнес-логики, это исключительно работа представления. Вы поменяли данные, но никуда не сохранили. Если это веб-интерфейс, то пользователь может обновить страницу, и все изменения пропадут. В десктопном приложении он может закрыть окно.
То есть в какой-то момент вам надо будет сохранить данные, чтобы изменения не пропали. В этот момент и начинается бизнес-логика. Она обычно работает на сервере, там нет вью-моделей. Загружается сущность по id, проверяется ее наличие, права доступа, новые данные загружаются в сущность, потом происходит сохранение. И вот тут иногда надо уведомить другие компоненты приложения. Например, сохранить какую-нибудь статистику. Тут могут быть любые действия, которые надо сделать после сохранения.
Большого смысла делать это событиями нет. Если есть контроль над кодом с бизнес-логикой, то лучше написать все вызовы явно. Чтобы программисту не надо было искать по всему приложению, если бизнес скажет "У нас там при таких-то условиях статистика не обновляется".
Но иногда нет желания или возможности менять код, в котором вызывается сохранение сущности. Например, иногда новую функциональность добавляют плагинами, которые реагируют на событие, а основной движок разрабатывает другая команда или сторонняя компания. Или считают, что модификация кода противоречит SOLID, хотя это не так, и намеренно усложняют поддержку приложения.
Нет, загуглил "саванна", открыл ссылку на Википедию)
Ну и что, анализ информации все равно нужен. Кто догадался использовать камень для выкапывания корней, тот будет лучше питаться.
Про любые виды. Вышли из леса, хоть в саванну, хоть в город, значит попали в новые условия. Приспособление к новым условиям требует анализа информации. Кто лучше анализирует, тот лучше приспособился. Иногда это имеет меньшее влияние. чем сила, тогда эволюционное развитие будет идти медленнее. Но все равно будет, потому что иногда будут появляться сильные и умные особи.
Необязательно, что они должны были возникнуть именно к текущему моменту. Может им просто времени нужно было больше, причин же меньше. Австралопитеки появились 4.2 млн лет назад и 1.4 млн лет жили в саванне, прежде чем появились первые Homo. Если в лесу умные обезьяны получают не такое большое эволюционное преимущество, как в саванне, и эволюционируют например в 3 раза медленнее, то сейчас они находятся только на уровне первых Homo. Мы примерно это и наблюдаем - базовые жесты, базовое использование орудий труда, использование лечебных трав. А речь у Homo появилась только через 800 тысяч лет.
Ну то есть если будет переселение, они могут выйти в саванну, и экологическая ниша человека тут ни при чем, потому что люди в саванне не живут. О чем и речь.
Перенаселение наблюдается, я же не просто так сказал про вырубку лесов.
Разные виды, поищите новости про обезьян и города. Те, которые живут не в лесу, очевидно, не будут заходить в города из-за вырубки лесов.
Ну то есть уже есть обезьяны, которые вышли в саванну. Почему вы решили, что через миллион лет они не станут умнее? Бабуины появились 2 млн лет назад, то есть позже австралопитеков. И хоть 1.4 млн лет с того времени уже прошло, нет такого закона природы, что это должно занимать именно 1.4 млн. Может быть 2 или 3.
А почему надо чтобы выходили именно человекообразные?
Ок, а как это связано с утверждением про экологическую нишу? Кто-то мешает обезьянам выйти из леса в саванну?
И как это означает, что причин становиться умнее в лесу недостаточно? Их может быть меньше, но они есть. У диких обезьян уже есть некоторые общепринятые жесты для коммуникации, они используют лечебные травы и орудия труда.
Более того, из-за вырубки лесов или в поисках пищи многие дикие обезьяны заходят в города, где им надо взаимодействовать с незнакомыми предметами.
Я уже объяснил почему - у вас недостаточно знаний, и вы не хотите их получать.
Там написано как.
Разделение на разные половые клетки есть даже у одноклеточных. Откройте ссылку и прочитайте. Также поищите, что такое мейоз.
Там написано как.
Не знаю, что вы имеете в виду, но я точно не имел в виду, что что-то появилось сразу.
С чего вы взяли, что не дающих в отдельности никаких эволюционных преимуществ? Потому что вам так хочется? Потому что лично вы не понимаете, какие были преимущества?
Вам уже много раз разные люди объяснили почему - потому что они давали эволюционные преимущества, либо как минимум не мешали. Не было никакого одного правильного направления, было много разных направлений, 90% направлений не получили эволюционные преимущества и исчезли, остались только 10%, от них и появились потомки. И с потомками так же.
То есть вы не способны взять и проверить в интернете, заморачивается она или нет? Или не хотите проверять, потому что опасаетесь, что узнаете информацию, которая изменит вашу точку зрения?
Ищите в интернете. Прочитайте статьи на Википедии про ДНК и хромосомы.
Были бактерии с одной копией ДНК, у некоторых бактерий она иногда билась на части под воздействием разных факторов. Большинство таких бактерий погибло, а некоторые остались. Потом у некоторых иногда к этим отдельным частям ДНК прикреплялись разные белки, большинство таких бактерий погибло, а некоторые остались.
Давайте я вам сразу дам ответы на все эти вопросы. По теории эволюции всё, что сейчас стабильно существует и воспроизводится, происходило последовательно-эволюционно. Вообще всё. Этому найдено много подтверждений.
"Последовательно-эволюционно" противоречит утверждению "ни с того ни с сего".
По теории эволюции это не является описанием последовательного эволюционного процесса. А является полной чушью. И так как вы намеренно ее написали, проигнорировав все объяснения, то это означает, что вы не хотите слушать собеседников, не хотите думать, и не хотите узнать нормальные ответы на свои вопросы.
У рыб, представьте себе, тоже есть внутреннее оплодотворение. И даже живорождение. И даже одна рыба может быть поочередно самцом и самкой. И даже некоторые способны к самооплодотворению.
Еще раз говорю, вы неправильно представляете, как происходят эти процессы. Видимо в силу недостатка знаний. И даже подумать не хотите. Поэтому вам кажется, что имеет мало смысла.
Смысла в случайном передвижении просто дофига. Потому что на другом месте еще есть еда, а на текущем уже нет.
То есть вы даже про фотосинтез не знаете? Фотодиод у водорослей дает прямое поглощение солнечной энергии, даже без всяких жгутиков.
Неправильно. Есть и одноклеточные организмы со жгутиками без реакции на свет (хемосинтезирующие бактерии), и одноклеточные с реакцией на свет без жгутиков (хлорелла).
"Без жгутиков" не означает "недоделанный", так же как и "без фотосинтеза" не означает "недоделанный". Они просто разные.
Примеры, которые я привел выше, говорят о том, что ваши представления о мире неверны. Предлагаю вам подумать о том, что вы не учитываете, раз ваши выводы не соответствуют известным фактам.
Ок, а причины-то чем отличаются? В лесу не надо коммуницировать? Строить жилища? Использовать подручные предметы?
Сначала появилось яйцо. Оно есть не только у куриц, а еще и у ящериц, динозавров, и даже икра рыб это разновидность яйца.
Вы не умеете искать информацию в интернете?
Википедия - Определение пола - Происхождение половых хромосом
Википедия - Гамета - Эволюция гамет
По второй ссылке написано, почему разделение на 2 пола лучше, чем 1.
А почему вы решили, что они оставались согласованными? Те, кто были не согласованными, не оставили потомства. Поэтому в следующих поколениях остались только те, кто были согласованными. И таких поколений было много. Теоретически даже всего двух согласованных особей достаточно, чтобы создать достаточное количество согласованных между собой потомков для поддержания нового вида.
Для более подробных ответов на детские вопросы читайте школьные учебники. Они специально для детей и написаны. Потом у вас будет достаточно знаний, чтобы искать и понимать нужную информацию в более серьезных источниках.
"Фотодиод со всеми нужными каналами" это в простейшем случае 2 клетки - приемник света и триггер мышцы или жгутика. Например, гидра. Даже некоторые одноклеточные умеют реагировать на свет.
С чего вы взяли, что жгутики не дают эволюционного преимущества?
А чем они, по-вашему, отличаются от причин, которые были у предков людей?
А зачем надо чтобы обязательно появлялись? Новые может и не появляются, но и существующих достаточно.
В статье и не говорится про отдельный фотодиод без канала. Там подразумевается фотодиод со всеми нужными каналами. Для анализа информации не требуется именно мозг, там же рядом в статье фотография моллюска.
Он и отличает. От фотодиодов сигнал приходит по одним нейронам, с диодов прикосновения по другим.
Он и понимает. В простом случае реакция нейрона сразу связана с действием, в сложном в середине есть дополнительная обработка.
Проблемы есть только в ваших представлениях о том, как это работает. Вы это представляете неправильно.
Экологическая ниша тут ни при чем, у обезьян в лесу причины становиться умнее никуда не исчезают от того, что люди в 20 километрах от них построили город.
Если вы под бизнес-логикой понимаете что-то другое, то у вас и будет не DDD, а какой-то свой подход.
Допустим, у какой-то сущности есть статус "На модерации". В это время пользователь не может ее редактировать. При попытке изменить любые данные API должно возвращать ошибку "Сущность находится на модерации" (допустим у нас сложный агрегат, и есть разные методы редактирования). Но прохождение модерации означает изменение статуса, а это тоже редактирование, но его делать можно. При этом самому пользователю не должно быть разрешено менять этот статус. Тут нужные проверки зависят от действия.
У меня тут потерялось слово "иногда". Но согласен, так будет работать, я сначала неправильно понял вашу мысль.
Логика в сервисах это вполне нормальное решение. Оно универсально, его можно использовать даже если у вас не сущности с базой данных, а стороннее API с названиями процедур, которое хранит данные на своей стороне. Все недостатки, которые можно найти у логики в сервисах, есть и у логики в сущностях, просто немного в другом виде. Только не все это замечают. У меня есть статья на эту тему с примерами кода, посмотрите если интересно.