Делай добро и беги

Подход понятен, имеет право на жизнь если в коде нет каких-то диких конструкций вроде сложного LINQ, dynamic-ов или анонимных классов. Тут было важно как можно точнее передать первозданный код, сохраняя комментарии чтобы команда не потерялась.

Грубо говоря всё, что можно распарсить в AST — всё можно рефакторить с помощью аналогичного подхода. Ну то есть вот трансляторы, да. Универсальный транслятор из одного языка в другой сделать сложно. Но для какого-то конкретного случая — вполне возможно. Даже для TFM :)

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

Выражается бажная идея в следующем: "вот смотрите, как хорошо управляются компании, какие там прекрасные менеджеры — давайте просто применим те же методики на государство". Это в нашей стране называется "технократический управленец", если я ничего не путаю. Так вот, можно было бы сказать что вы видели дааалеко не все компании: некоторые управляются так, что даже видавший виды эксперт поражается происходящей тупости. Но это не самое страшное.

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

Есть у нас в СНГ один такой… руководитель времён СССР, крепкий хозяйственник, который тоже любит смотреть на показатели и надои. Сейчас ему вся страна голову хочет открутить.

Мы наблюдаем тотальную некомпетентность руководства многих государств, но потрясающий профессионализм в успешных IT-стартапах.

Вы меня простите, но я перестал читать дальше этой строчки.

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

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

Неочевидно как именно DDD позволяет управлять возрастающей сложностью. Какие его механизмы обеспечивают снижение сложности логики? Может, какие-то архитектурные способности способствуют лучшему пониманию происходящего и обмену информацией между командами?

По мне так — у нас есть куча агрегатов, каждый из которых делает что хочет, да ещё и на события реагирует, которые непонятно где и когда возникают. Это только усложняет понимание картины происходящего.

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

Правильно ли я понял что за доменную сущность заказа и доменную сущность товара должны отвечать разные команды?

При чём здесь консистентность? Я говорю о том, что логика операции размазывается по куче сущностей и её неудобно собирать воедино.

А это здесь при чём?

Пятиминутка саморекламы: если вам всё ещё хочется банан — посмотрите Tecture. :)

Поправьте меня если я ошибаюсь, но не означает ли это что одна целостная бизнес-операция (которая по всем правилам хорошего тона должна быть ещё и атомарной) — оказывается разнесена по куче классов с логикой, да ещё в придачу со сложным графом вызовов? Реакции на события всегда сложно отлаживаютя.

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

Как в этом подходе будет выглядет операция бизнес-логики, вовлекающая в себя 16 агрегатов?