покажи пример как устранение геттеров повышает связанность и сможем обсудить. Вся идея в том что бы связанность уменьшить.

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

забудь о слоях. они тебя отвлекают от главного.

перечитай у эванса пример с монтажем фильма в начале книги)

Пример: мы осбуждали пример бои юнитов в соседнем чате недавно, как обойтись без геттера, чтобы рассчитать бой. Вариант (вы предложили) - передать в сущность сервис, и сама сущность передаст данные в этот сервис, не отдавая данные наружу. Сущность знает о сервисе - это разве не будет увеличеснием связанности?

Ну я перечитаю, но у эванса слово workflow 2 раза в книге только встречается. Я не совсем понимаю почему вопрос про сервисы не нужно задавать. Где-то же нужно определиться с юзкейсом бизнес логкик

а bounded context? вот bounded context это activity внутри workflow/value chain

buisness capability оно же

А вы сравните где общедоступный публичный интерфейс больше.
Когда у вас экспозится все кишки наружу и говорят используйте меня кто хотите. Или определенный независимый сервис котрый просто контрактом просит в него что по положить
Итого у нас нет протекания внутреного стейта в стейт всего приложения
Создавая акцессоры вы как бы увеливаете управляемый стейт всего вашего приложения которое может их использовать

как парвило сущность — это некоторая простая стейт-машина в общем случае

дял стейт-машины обычно есть методы выяснения, находится ли она в корректном состоянии

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

Используйте мои данные для своих целей, а не меня, так наеврное будет точнее. Из минусов вижу такое: при увеличении кейсов, сущность (в которую передают разные сервисы) будет расти + повышается риск мерж конфликтов.

Я не понимаю. Мне не обращаться внимание на термин application service, потому что не важно как я назову то место, где у меня workflow определяется?

Ну, например, у тебя есть А и ему для чего-то там нужна инфа, которая есть в Б. Ты либо сделаешь какой-то геттер в Б, и передаешь результат этого геттера в А (таким образом Б ничего про А знать не будет), либо же ты вынужден сделать так, чтобы Б знало про А.

Давайте на примере тех же заказов и товаров, пример с геттерами:

class Order {
    OrderLine[] orderLines

    addProduct(Product product) {
        this.orderLines.push(
            new OrderLine(product.id(), product.name(), product.price())
        )
    }
}

Здесь у меня у продукта есть 3 геттера (понятно, что можно это в какую-то структуру запихнуть (как ProductSpecification), но не суть).
В этом примере Product ничего не знает про Order.
Пример без геттеров:

class Order {
    OrderLine[] orderLines

    addOrderLine(OrderLine orderLine) {
        this.orderLines.push(orderLine)
    }
}

class Product {
    addToOrder(Order order) {
        order.addOrderLine(new OrderLine(this.id, this.name, this.price))
    }
}

Здесь у Product’а геттеров нету, однако ценой этому стало то, что теперь он знает про Order.

С вашим подходом (логический каплинг) лучше акцессоры.
Нормальное процедурно структурное програмирование
Где объкты как структуры используются

я вот плюсану за пример выше :) Примерно тоже самое имел ввиду

Я не за ни против, я с тем же вопросом и примером :)

есть и третий вариант , когда product создает этот orderline. Но это не меняет вообще никакого глобального смысла.

Еще раз вы хотите и используете процедуное програмирование со структурным. Без изменния самого подхода нет смысла боротся с акцессорами. Это часть вашего подхода.
Могу только для вашего примера порекомендовать в который раз  AllYourAggregatesAreWrong.
Там прекрасно без акцессоров обходятся.

Мне кажется AllYourAggregatesAreWrong и текущий вопрос о разных проблемах.

имхо, на таком маленьком синтетическом примере это видно плохо. Когда большая кодовая база, где эти геттеры дергаются чаще можно например заметить, что product.name(), product.price() всегда дергаются вместе. и потом например когда потребуется добавить некий новый параметр продукта, надо будет искать где оно используется и везде менять в 20 местах. И тогда может возникнуть мысль, что может быть в этом месте гораздо удобнее было бы передавать не имя и цену а что то другое

По делу ничего не сказали, без обид)
Второй мой пример обходится без аксессоров тоже, и что?

Я и написал, что можно завернуть это в какую-то структуру, суть вопроса не в этом.