Групповая работа — исключительно на административном уровне. То есть, система папок (packages) с административным контролем доступа.
Версионирование диаграмм — не использовали. Проводили ежедневное архивирование и ставили в важные моменты времени метки.

Почему так поздно объявили?

Обязательно напишем о нашем опыте применения микросервисов, например, в интернет- каналах.

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

В статье нет ни слова о том, что ESB это плохо. Напротив, удачные реализации этого паттерна показывают его неоспоримую пользу. Но MSA предлагает другой подход к интеграции. Подчеркиваю, не говорится, что он лучше или хуже, чем в SOA, но другой.
Децентрализация в MSA – один из основных принципов. ESB же по определению является центральным и единственным звеном, отвечающим за интеграцию. Здесь и минусы, и плюсы. С моей точки зрения, ESB реально решает проблемы интеграции (трансформация, маршрутизация, технологические различия, обработка ошибок, логирование, мониторинг) и консьюмеры и провайдеры от этого выигрывают. В MSA каждый сам за себя. И сложность интеграции (все что перечислено в предыдущих скобках) остается в самих микросервисах. Best practices в MSA решать это с помощью инфраструктурных библиотек, что скрашивает эту проблему.

Один сервис может развивать одна команда не более чем из дюжины человек.
Один сервис может быть полностью переписан одной командой за одну Agile-итерацию.

Я один вижу тут противоречие?

Все четыре пункта, приведенные в статье, противоречат друг другу, в той или иной степени. Они все являются индикативными. Достаточно выбрать один из них и ориентироваться только на него.

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

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

С такими агитаторами микросервисной архитектуре врагов не надо, «друзья» со всем справятся сами.

Да. Такая негативная «агитация» является намеренной. Именно для того, чтобы использование микросервисов было осознанным, а не для строчки в резюме.

Если говорить о SOA, то начнем с того, что это все же больше про интерфейсы, за которыми скрывалась сложность реализации. То есть реализация, все же отдельно. В то время как MSA предлагает принципы и того и другого. Сравнивая принципы интеграции этих двух подходов, безусловно, можно найти много одинакового. Здесь я соглашусь, что MSA берет лучшее от SOA. И это правильно. Но все же есть и различия, и они представлены в части под названием: Интеграция. Если говорить о противопоставлении, то с моей точки зрения, все же правильнее делать это с точки зрения монолита и MSA. Но опять же – это не значит, что одно лучше, а другое хуже. Просто такое сравнение получится более многогранным.

Да. Это стандартный подход. Я даже подозреваю, что и типы вьюшек получаются похожими. Различие в их вариациях и количестве. Что в свою очесредь в основном зависит от того, как много и какой сложности достоверных данных для этих вьюшек сможет поддержать предприятие.

Смотрели безусловно. Его идеи очевидны в нашем варианте. Но все-же Archimate значительно сложнее. И это ответ, почему мы его не используем. Конечно, такая кастомная модель — это изобретение велосипеда, но этот велосипед очень уж хорошо нам подходит. По этому поводу, я встречал классное высказывание писателя Артура Хейли. Дословно не помню, но приблизительно так: «Всю музыку уже написал Чайковский, но все равно ее пишут и пишут.»

Кстати, разработчики Sparx EA уже выпустили бета версию тонкого клиента. Скоро обещают стабильную версию. Тогда интерактивность будет настоящей.

Репозиторий один, поскольку, все элементы хранятся в одной базе данных. С интерактивностью сложнее. Это в Sparx EA организовывается по- разному. Как правило, от одного элемента можно перейти к другому при наличии связей между ними. Другими словами, если в вашей модели предусмотрена трассировка от одного слоя к другому в виде связей, то вперед. Только не забудьте, что заведение связей – это ваше дело. Если они есть, то можно блуждать между элементами и слоями. Если говорить про настоящие гиперссылки, то тогда нужно экспортировать репозиторий в html- представление. Здесь интерактивность будет получше. Но на практике, для анализа табличное представление гораздо эффективнее. Тогда при правильной вьюшке не придется терять на экране информацию о предыдущем элементе, переходя к следующему. Именно об этом говорится в последнем абзаце статьи.
В нашем случае от Use Cases можно дойти по «гиперссылкам» до Типов Данных. От компонентов прямой трассировки нет. Но есть вьюшка, которая обеспечивает такую информацию на одной странице через более сложный SQL-запрос.

В нашем случае, проблема решена следующим образом. Типы данных относятся к элементам уровня архитектура данных. Сами типы иерархические. Типы топового уровня, как правило, обладают небольшим набором атрибутов самого общего характера. Далее в зависимости от важности типа, от частоты его использования, от ваших возможностей и желания он (тип) может детализироваться на более низкие уровни иерархии. Например, Болванка (ну очень важный в данном примере тип) имеет атрибуты Длина и Вес. И его (тип) можно разобить на ERP Болванка (с дополнительным атрибутом Код) и Станочная Болванка. Ну и так далее.
Уровень детализации не обязательно одинаков для всех объектов. Чем важнее объект, тем больше внимания мы ему уделяем, тем больше атрибутов и сложнее иерархия.
Причем мы всегда остаемся на логическом уровне представления типов. Физический уровень систем или баз данных мы не поддерживаем принципиально. Это очень сложно.
И не забудьте, что чрезмерная детализация будет требовать чрезмерных усилий при поддержке актуальности репозитория. Ну а что такое «чрезмерный»- каждый решает сам.