Я не могу на уровне понятий понять отличие. Если антикоррупционный - частный случай трансляционного, то как можно охарактеризовать те особенности, по которым можно отличить именно антикоррупционный слой?

честно - не сказать что я помню что такое translation layer, обычно только про anti corruption говорят. Сам по себе anti corruption layer он про защиту модели от внешних факторов (фасады + адаптеры которые позволяют взаимодействовать твоей модели и "чьейто чужой".

я думаю достаточно разобраться с идеей зачем надо делать эти прослойки на границах между системами.

Подскажи, как в коде обозначаются bounded context'ы? Папками / файлами / неймспейсами?

И какое количество таких контекстов — норма? Я имею ввиду порядок — единицы, десятки, сотни. Понятно, что всё зависит от сложности системы, но если представить какую-то более-менее сложную, сколько там будет контекстов?

"модулями". Кто-то вообще каждый контекст в отдельный репозиторий выносит (микросервисы).

кто-то дробит еще больше (по фичам отдельным а не контекстам).

дальше от языка зависит. У многих языков "папка" модуль и пакет это одно и то же

Да именно так. Вот пример из книги про антикоррупционный слой.

Но дальше встречается такой текст: для взаимодействия двух контекстов вам придется построить трансляционный ровень - возможно даже антикоррупционный уровень.

То есть антикоруппционный- это более сложный трансляционный. Но где проходить граница между этими понятиями, не могу пока понять.

паттерны у эванса это по-сути его варианты решений.
которые он описал до популяризации современных

все так потому я бы не загонялся по его решениям

> Вообще не знаю, кто придумал в ООП наследование - его всегда можно заменить композицией, улучшив при этом DIP и OCP.
> Наследование же нарушает чуть ли не все СОЛИД-принципы

вот да, наследование можно заменить композицией. С этим я бы согласился. Равно как и наоборот. А вот как dip и ocp улучшается? всегда полагал, что солид все же про интерфейсы, а то, какой класс (с/без наследования, с/без композиции) какие интерфейсы имплементирует - это его дело, и никак на солид не влияет.

>Это декларация поведения (интерфейс). Наследование в классах - это немного другое. Отстуствие множественного наследования как бы "намекает" на то, что наследование - это плохая практика ;)

Так ведь можно так:

class m1 {
   abstract m1() {}
   abstract m2() {}
   abstract m3() {}
   m4() {
       m1(m2(m3()))
   }
}
class m2 extends m1 {
   m1() {  }
   m2() {  }
   m3() {  }
   m4() { super.m4() }
}

А почему плохая?

> Спроектировал ООПшник модель телевизора и модель пульта для включения телевизора. Поставили задачу "включить телевизор", а пульт где-то затерялся. Вместо того, чтоб включить телевизор, ООПшник долго ищет пульт по всей квартире - ведь именно пультом (по его задумке) "правильно" включать телевизор. Или даже пульт есть, а вот  "модель батарейки" в нём села. И ООПшник, вместо того, чтоб включить телевизор, бежит в магазин за новой батарейкой для пульта к телевизору ("В доме, который построил Джэк")

> Завтра люди научились силой мысли включать приборы без пульта - и ООП-ник понял, что надо рефакторить весь проект, ведь без модели пульта его код просто не запустится.
У ФП-шника просто была функция, включающая телевизор. У него не было объектов. И ему было всё равно кто и чем тот телек включает. Правда, поскольку у него не было и модели телика, то по факту он включил что-то другое (например, ядерный реактор) - но это уже другая история...

Если телевизор можно включить из пульта, а еще можно напрямую непосредственно включить, то, мне видится, это нарушение srp, т к у телевизора 2 актора (человек и пульт) - в этом случае, мне видится, надо разделять телевизор на 2 типа, и тогда снова нет проблем. Если же это означает, что на каждый чих надо рефакторинг делать, то да, надо, ведь поменялось требование к поведению (последовательность вызовов методов). Но можно и защититься от этого - сделать все классы контроллерами, и вызывать их откуда угодно в любой момент времени. Только зачем это надо?

А репозиторий можно считать антикоррупционным слоем?

на тему количества контекстов - а сколько отделов/специализаций может быть в крупном бизнесе? Возьмем скажем интернет магазин. У нас есть мерчендайзинг, есть менеджеры по продажам, есть складской учет, есть бухгалтерия, есть курьерская служба...

Их обычно не один. Udi Dahan например говорит что "обычно штук 10 не больше, если у вас больше значит либо у вас прям мега огромный бизнес либо что-то пошло не так.

да, ведь это адаптер который скрывает как ты мэпишь штуки на базу

Это инфраструктурный, который обеспечивает хранение сущностей. Я так понял сам интерфейс репозитория мы храним в домене, а вот реализации в инфраструктуре.

у Эванса это называется anti corruption layer. Всякие Кокберны и Дяди Бобы потом уже начали вещать про луковые штуки и прочие гексагоны

Во, отлично, спасибо. А то я уже начал выделять "админский контекст" для админки, где бизнес-сущности предствляются иначе, чем для логики. И репозитории у них там свои 🙂

Видимо, свернул не туда

декомпозиция логики через UI это классическая проблема на которую напарываются люди. У многих в компаниях так организовано даже разделение работы (и потом они удивляются почему зависимости на каждый чих). Следующий возможный косяк - контексты выделять только на основе структуры компании (как будто они не могли накосячить)

просто про conway law читай короч. проблемы с зависимостями и взаимодействиям частей твоей системы будут те же что и проблемы с коммуникациями и зависимостями в организации под которую система делается