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

"Итак, предположим есть куча микросервисов. Один из них работает с юзерами. Предположим пришел новый сотрудник, мы сделали нового юзера. Как только это произошло, надо запустить кучу других процессов. Например: надо отправить нового сотрудника на Security Training, после этого ему можно дать доступ в сеть, выдать ему комп, создать аккаунт и все такое. Это мы сделаем через workflow. Но есть функционал, который можно направить в сервис прямиком. Например: вдруг выяснилось, что дата рождения была неправильно записана, надо ее просто изменить, просто тупо изменить данные в таблице. Итак, возникает такая маленькая проблемка: иногда нужно перехватывать вызовы к микросервису и стартовать workflow, а иногда можно и просто вызывать сервис. Где хранить эту логику?"

Здесь в картине мира разработчика нет ничего, кроме "какого-то" кода и "микросервисов", под которыми понимаются произвольно размазанные по узлам сети компоненты приложения

Практическая иллюстрация тезиса выше 👆в виде задачи.

Итак, есть таблицы t1 с записями id = 1, 2 и t2 с записями id = 1, 1, 2, 2. Сколько записей будет в результате выборки из t1 LEFT OUTER JOIN t2 ON  t1.id = t2.id?

Если вы ответили, что 2, то у меня для вас плохие новости, ребят: теория говорит, что outer join это inner joib + вариативная delta. Inner join это 4 строки

Одна из очень чувствительных потерь при переходе на микросервисы — прощай, аналитика! Если в случае с монолитом у вас были наизготовку ETL-технологии, и всё, что вокруг них, то теперь единого источника данных не существует: вам нужен свой консолидатор, который уже и будет демонстрировать данные в нужных разрезах. При этом с каждым микросервисом и его частным хранилищем придётся работать по-своему — как технологически, так и с точки зрения регламента актуализации общего аналитического "куба" (или что там у вас)

Ситуация 👆настолько серьёзная, что многие проектировщики в real world, а не в книжках по микросервисам приходят к мысли, что общая для всех микросервисов (!) разделяемая (!) интеграционная (!) реляционная (!) БД — не такая уж и плохая вещь (читай — доступные альтернативы сильно хуже). Вот пример https://www.quora.com/Microservices-How-is-reporting-implemented-in-a-micro-service-architecture.

"А как же микросервисы, изоляция, своё наиболее подходящее хранилище в каждом юните развёртывания? ведь в книжках пишут.. пишут.. ведь авторы не будут врать.."

=> Мало ли, что там пишут. И вы пишите!

Чтобы по проблеме выше не изобретать свой наколеночный ETL, можно использовать:
- брокеры сообщений и стримов (типа Kafka), и инструменты поверх них (apache drill, apache ignite)
- готовые платформы витрин данных
Т.к. мы используем преимущественно опенсорсные продукты с перспективой покупки платной поддержки при необходимости, подходящая витрина для нас это http://teiid.jboss.org/
Выполненный как подсистема для Wildfly, Teiid позволяет объединить различные EIS в "виртуальную" базу данных, с которой можно работать при помощи SQL-подобных запросов. Может вам подойти

Выбор технического стека для некоторых вопрос очень тонкий. Для нас это вопрос издержек, простоты сопровождения и всего того, что называется сosts of ownership. Кроме того, не хотелось бы сильно ограничивать себя вендором, и не отставать от индустрии.

Таким образом мы пришли к решению использовать JBoss Wilfdly.

Кратко перечислю плюсы:
* WF это зрелое решение, достигшее версии 10. Поддерживает Java 8 и JavaEE 7 Full Profile, включая распределённые транзакции и JMS, асинхронную обработку запросов через XNIO, вебсокеты и другие модные штуки
* WF это опенсорсное решение, которое активно развивается. При необходимости можно докупить платной поддержки у JBoss, владелец которой — RedHat
* WF это просто набор модулей, конформных стандартам JavaEE. В отличие от закрытых продуктов, здесь можно отключить те или иные модули, или привезти с приложением свою реализацию. Ядро сервера — небольшая библиотека, читающая конфигурацию и организующая класс-лоадеры для того, чтобы приложение получило JavaEE API. Написать свой модуль или патч дефекта — не проблема, мы уже это успешно делали
* Предыдущий пункт значит так же, что замена модулей на более свежие для сервера в целом или для конкретного приложения задача понятная и несложная
* WF оборудован набором неплохих расширений. Среди них:
~~ JDG, JBoss Data Grid (Infinispan) — распределённый транзакционный кеш, который можно собрать в реплицируемый режим (с избыточностью) или DHT, write-trough или отложенную запись;
~~ Switchyard, позволяющее декларативно описывать бизнес-процессы и другой оркеструющий код (тоже на базе открытых проектов типа Apache Camel)
* На WF есть набор неплохой документации, не дающий нам погибнуть
* К нему есть консольный shell, позволяющий скрипты инициализации писать очень легко и просто
* У WF есть хорошая графическая консоль, включающая в т.ч. средства мониторинга. Управление сервером через JConsole не обременительно
* Система логгирования настраивается легко и пишет всё необходимое

Если вдруг вам понадобится поддержка JavaEE, предлагаю посмотреть в эту сторону

Вы, наверное, знаете, что я приветствую системную инженерию. И не приветствую советских инженеров (en masse, а не конкретных талантливых самородков). В FB нашёл пост, и не могу не прокомментировать его тезисы (https://www.facebook.com/shperk/posts/10158473637240153).

Я скопирую весь текст сюда и прокомментирую:

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

2. Инженерия в сравнении с научной деятельностью слабо отрефлексирована. Основные механизмы воспроизводства: подражание мастеру, личный опыт, прототипы, традиционное обучение.
Это было верно примерно 70 лет назад, но не сейчас. Правильно здесь - отослать читателя к зарубежной литературе

3. Почти каждая настоящая инженерная задача – уникальна.
Но это не повод опустить руки. Кроме того, по всей видимости, налаживание системы массового производства не есть НАСТОЯЩАЯ ИНЖЕНЕРНАЯ ЗАДАЧА. Вот так в СССР и не появилось качественной бытовой техники, автомобилей и многого прочего

4. На разработку технического изделия претендует и проектировщик, позиция которого в социальном отношении сильнее, поскольку он готов иметь дело с типовыми изделиями и любыми (а не только природными) процессами
Ох уже эти проектировщики (смотрит снисходительно), собирают из готовых кубиков, не то что суровые НАСТОЯЩИЕ инженеры.

5. Социальный запрос, конечно, существует и на инженерию, особенно для уникальных разработок и условий (конкуренция, война). КБ, НПО, ЦНИИЭПы.
Ура! Даёшь шарашки! Что советскому инженеру ни дай, выходит НКВД с шарашками.

6. Инженерное сообщество (исключая США и Германию) не смогло сорганизоваться и противостоять другим институтам. Поэтому инженеров ассимилировали институты науки, проектирования и производства.
Чистой инженерии (как pure science) вообще не место в индустрии, это невесомое неосязаемое ничто

7. В этих институтах и образовании инженерное мышление существует как «производный институт», т.е. воспроизводится за счет институциональных механизмов тех институтов, в которые оно входит.
С этой мыслью тяжело свыкнуться тем, кто ищет некоторый Священный Грааль инженерии. Хороший инженер — это и физик, и лирик в одном лице.

Вы можете не разделять моё критическое настроение, но всяко не следует относиться снисходительно к инженерному опыту остального мира вне СССР.

Негативные коннотации у слова "архитектор" достигли таких масштабов, что не только в своих внутренних процессах, но и вовне мы начали предпочитать термин "главный инженер проекта" (ГИП).

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

ГИП у нас это ещё и проводник практик системного подхода и инженерного менеджмента в проекте.

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

Постановка проблемы гораздо важнее ее решения. Решенные проблемы исчезают в прошлом, а нерешенные - рождают будущее.

Немного выступил для Школы Системного Анализа на правах гостевого лектора. Тема "Моделирование корпоративной архитектуры. Человеко-машинные слои" https://www.youtube.com/watch?v=whV64pahBhA

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

Все списки хороши, когда в них мало пунктов, и они обозримые. Мой чеклист критериев хорошей архитектуры таков:
1. она учитывает такие интересны разных людей, о которых не задумываешься (например, компетенции команды разработки и ресурсы команды тестирования).
2. она аддитивная (т.е. позволяет не менять уже написанное, а добавлять).
3. она позволяет откладывать глобальный рефакторинг как можно дольше, в идеальном случае — за пределы времени жизни системы

Мне при взгляде на эту картинку приходят такие мысли из книги "наставление сержанта полевой службы":
- даже самую простую вещь не одолеть без тренировки

"Среди дикости и невежества появляется посланец прекрасного мира будущего. Он порой даже не понимает, как можно жить так глупо и чудовищно. Надо все исправить. И тут начинаются проблемы. Можно ли вмешиваться в ход истории? Можно ли одним прыжком перейти от дикости к цивилизации? Достаточно ли просто освободить людей от тирании и дать им свободу выбора?"

Следующий раз, когда вы будете внедрять своё гениальное решение, посмотрите на себя с такой стороны

Меня просили высказаться по поводу RAD-тулов и систем (rapid application development). Так что же я могу сказать по этому вопросу? Н И Ч Е Г О

Rule of thumb, основанный на опыте: если кто-то употребляет слово "качественный", он, как минимум, добросовестно заблуждается, а очень часто — ещё и знает о большой неправде

Тема, немного отклоняющаяся от конструирования систем, но всё равно очень важная — управление проектом, т.е. часть структурирования обеспечивающей системы. Принёс вам про управление проектами из СССР из того времени, когда там уже случился закат управления, но изобразительное искусство было ещё на коне https://www.youtube.com/watch?v=B1D1nl7jUBE