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

да уж кодим, куда ж теперь без этого. все ж хипстеры кругом...

#entarch frameworks are typical monoliths which have to be disassembled for better architecting https://lnkd.in/dZAKNfw

Проблема в том, что пока 10 аналитиков изучают Archimate, хипстеры уже релизятся на бой...

Это по аналогии с тезисом о том, что - ESB (и прочие ETL, BPM) - для поддержки legacy applications. Так и архитектура нужна для этого. Для удержания в голове того, что активно оттуда вытесняется ) Хипстеры же держат в голове все постоянно, поэтому у них legacy нет )

Это чей такой тезис? Я лично про ETL и BPM ничего не говорил. И дело не в держать в голове

Про ESB - @mxsmirnov . Про остальные я дописал. Согласен, что ETL еще можно отнести к вещам не legacy, но BPM - точно оттуда.

Если ваш автомобиль стоит как Феррари, а едет со скоростью Лада, то возможно с ним что-то не так.

СтоИт как феррари )

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

Почему нельзя писать код? Инфраструктурщиков хотим заставить все в код перевести, а сами без перьев ничего не можем?
Можно и нужно все описывать кодом. И ещё чтобы была возможность реверс-инжиниринга из кода разработчиков.

Можно. Только не очень понятно, зачем. Большую часть работающего кода сейчас генерируют платформы и Фреймворки. С точки зрения архитектуры реализация большинства бизнес-требований не имеет значения и может меняться, переделываться, переписываться - и это архитектуру практически не затрагивает. Так зачем архитектуру переводить на создание кода? По крайней мере, сразу

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

На всякий случай, уточню - я не говорю, что архитектор не должен писать код (хотя где-то по чату выше было обширное обсуждение, почему не должен). Тот же Ньюман одним из преимуществ микросервисного подхода называет возможность архитектора участвовать в разных командах разработки и самому писать часть кода. Я говорю, что подход Everything as a Code уже работает в архитектуре, даже если архитектор сам код не пишет. Он (подход) работает через формирование архитектурно значимого кода (например, каркасы сервисов, интеграционные сценарии и т.д.) с использованием CASE-средств или IDE, интегрированных с Middleware (например, jDeveloper позволяет проектировать интеграцию для SOA Suite от оракла, который генерируется в интеграционные сервисы)

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

Максим Цепков на Analyst Days высказал мысль, что если результаты архитектурного анализа (например, диаграммы модели данных, классов, интерфейсов, сиквенсы и т.д.) не позволяют сократить работу по их реализации в коде (в идеале - генерировать код), то время на их создание потрачено зря. Не скажу, что совсем согласен с этим, но похоже производители CASE-средств и IDE действительно постепенно приходят к этому и позволяют создавать полурабочие каркасы для последующего наполнения неархитектурным содержимым. Типа реализации методов и т.д.

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

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

А кто-то использует генерацию кода из моделей? Я имею ввиду, до уровня реализаций методов, чтоб сгенерировал и сразу в билд? По-моему это что-то из уровня фантастики

кстати, надо сказать, что Максим очень активно пропагандировал DDD, где у всех одинаковая предметная область. Так что наверное это не лишено практического смысла