Анемичности не будет. Ибо главное держать правила инвариантов рядом с данными на которые они влияют. Какие-нибудь бизнес расчеты можно держать отдельно. Главное, чтобы этот интерфейс который ты юзаешь для поддержания инвариантов был вместе с данными

Спасибо за дополнения 👍🤓

Я правда не могу понять следующее. Выходит бизнес логика - это самая абстрактная вещь по всем этим линиям . Но как она может быть абстрактной - у нас конкретные задачи бизнеса? Или это речь не про abstract и interface ? Просто если брать какие нить репозитории, работу с избражениями еще с чем то, тут все понятно с абстракциями, а вот про то что бизнес логика доложна быть абстрактной - не очень. Делать интерфейсы на сущности и доменные сервисы? Выше делать интерфейсы на юзкейсы? Если да, то зачем, какой практический смысл?

бизнес логика не может быть абстрактной вообще. это вообще как ? Само понятие лишено смысла

> Делать интерфейсы на сущности
точно нет, если ты собираешься извращаться как-то и проводить всю работу с энтитями / вельюобжектами и пр через абстракции (однако, сущности могут реализовывать какие-то интерфейсы или абстрактные классы, чом бы и нет, это просто средство языка)

> доменные сервисы
если он потребляется кем-то, то можно

> Выше делать интерфейсы на юзкейсы
в каком-нибудь клине / гексагоне обычно так и делают

смысл абстракций в том, чтобы инвертировать поток зависимостей. это позволит хорошо и правильно проектировать устойчивые сервисы, сервисы с низкой связанностью, упростит тестирование, позволит более независимо изменять части системы без аффектинга других её модулей

про абстракции и абстрактность я выше писал. В клине говорится не о том, что БЛ должна быть какой-то абстрактной (этот термин сам по себе абсурден), БД и устойчивые компоненты должны менеджить неустойчивые через стабильные абстракции
https://t.me/oop_ru/176522
https://t.me/oop_ru/176525

Просто ранее было написано, что уровень абстракции повышается к домену. Но типо саму бл это не касается?

Зачем нужно отделять реализацию от интерфейса? Для документации?

бл НЕ может быть абстрактной. как это вообще ? У тебя есть конкретные рулы, надиктованные твоим бизнесом

но реализация БЛ может потреблять некий набор абстракций и управлять ними. но это не делает её абстрактной

Ну вот я тоже не могу понять как это. Видимо не правильно понял посыл

А ещё немогли бы уточнить, пожалуйста, что вы под устойчивым компонентом подразумеваете.

Просто ощущение что немного иначе чем в книге

Устойчивый компонент имеет минимум зависимостей от других компонентов

нит, ни правда

ну, от части, ладно :)

у устойчивого компонента есть причины, по которым нам не хотелось бы его изменять, т.к. это может аффектнуть всю систему. это если грубо говоря. обычно это или компоненты, к-ые или кем-то потребляются и не имеют зависимостей (как написал Юрий), или компоненты, к-ые менаджат другие компоненты

Чистота = Эстетика?

Ну тут с 2 сторон просмотреть можно

1. Направление в сторону стабильности/абстрактности. Больше про зависимость модулей.

“Нам не нужны компоненты, часто изменяющиеся по самым мелким причинам и влияющие на другие компоненты, которые иначе были бы вполне стабильными. Например, косметические изменения в графическом интерфейсе не должны влиять на бизнес-правила. Добавление и изменение отчетов не должно влиять на высокоуровневые политики. Следовательно, граф зависимостей компонентов создается и формируется архитекторами для защиты стабильных и ценных компонентов от влияния изменчивых компонентов.”

По идее правильно, но с другой стороны у большинства так редко меняется какой-нить API без изменения бизнес правил, что это не кажется интуитивным.

2. Можно на более мелком уровне посмотреть:
Вот функция f1 вызывает функцию f2. Функция f1 зависит от интерфейса функции f2. И код f2 тоже зависит от интерфейса f2.
Но с помощью констукции интерфейса - мы можем положить интерфейс f2 ближе к f1.

Спасибо 👍

теперь можно ссылаться на правила при ревью ссылкой, а не по номеру)