ты вроде один такой крутой)

в книжках пишут, что spring cloud data flow наоборот, убирает девопсов. Или когда их вообще нет.
Кстати, тут прогеры а не девопсы)

это и есть менеджер докеров. Причем тут спринг?
Ты кубернетис настроил?
10 докеров работают?
3 хоста для контейнеров есть?

не слышал.
Монолит это везде Г архитектура.

Ещё раз
Монолит противоречит SOA.
с какого года SOA?

не читай его.

ну дак рано вопрос поднял про оркестрацию.
Согласись.
Нельзя учить прогеров если сам не писал.

mad_nazgul,
Нашел.
Монолит не пишут с 1998 года. Когда появилось Jini
))))))

не верю.
Слово монолит придумал Ньюман?

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

давай не будем про африканцев, если мы в европе.
Берем проект ИС Завод.
Далее эту ИС по ГОСТ мы функционально описываем.
Это и есть куски.
Интегрировать проект ГОТОВЫЙ завод с 1С?
Зачем тут такое рассматривать?

многомодульные в git состоят из отдельных репо.
То есть нету одного репозитария.
Сразу архитектор сделает 4 репо ОТДЕЛЬНЫХ.
А потом при желании вставит один в другой подмодулем.
Итого нет понятия Монорепозитарий и Монолит и Монолитные микросервисы (недавно было)

согласен.
Пусть автор сделает 3 класса и 3 модуля.
А потом вопрос задаёт.

их нельзя подключить пока нет отдельного. Так?

угу. И ТЗ вы не пишите. И бизнес аналитика нет.
Тогда конечно.

я к тому что подмодули в git это просто синтаксический сахар. Как ссылка на файл в линуксе.
Сам файл лежит где надо, а ссылку воткнул в сюда.
Это не деление на подмодули. Делит отдельный репо
/Торговля
/Производство
/Бухи
То есть обычный проект и никак не монолитный.

наоборот. Практический.
Ты мне дай общее репо и я напишу так


И ты потом через 3 дня ничего не разделишь))).
Зы.
Радетели микросервисов сами предлагают писать монолиты в монолитном репо).

qasta,
Вот ТЗ
автор4. Требования к системе
4.1. Требования к системе в целом
4.1.1. Требования к структуре и функционированию системы
Определяется перечень функциональных подсистем, их назначение и основные характеристики, требования к числу уровней иерархии и степени централизации системы.

Система КХД должна быть централизованной, т.е. все данные должны располагаться в центральном хранилище. Система КХД должна иметь трехуровневую архитектуру (можно привести общую схему, на которой определить уровни. Например, первый - источник, второй - хранилище, третий - отчетность).
В Системе предлагается выделить следующие функциональные подсистемы:
- подсистема сбора, обработки и загрузки данных, которая предназначена для реализации процессов сбора данных из систем источников, приведения указанных данных к виду, необходимому для наполнения подсистемы хранения данных;
- подсистема хранения данных, которая предназначена для хранения данных в структурах, нацеленных на принятие решений;
- подсистема формирования и визуализации отчетности, которая предназначена для формирования бизнес-ориентированных витрин данных и отчетности.

Указываются требования к способам и средствам информационного обмена между компонентами системы.

В качестве протокола взаимодействия между компонентами Системы на транспортно-сетевом уровне необходимо использовать протокол TCP/IP.
Для организации информационного обмена между компонентами Системы должны использоваться
И вопроса деления на модули нет ещё с времен СССР.

о, ещё один термин).
Путь ТС изучает оркестровку веб сервисов и докеров. Если ему это надо.
И начинает с Hello World.

недавно гарант выступил за чистоту русского языка. Я за чистоту терминов.
Это пятая тема про монолит, которого нет.

qasta,
Да. Консенсус. Согласен.

А тут?
https://www.google.com/search?newwindow=1&sxsrf=ACYBGNT4F1AOL_epJYg9dLgYvW_er6Mn5g:1573196565783&ei=FRPFXf22L4rQrgS6vIK4Ag&q=Микросервисы buzzword&oq=Микросервисы buzzword&gs_l=mobile-gws-wiz-serp.3..33i160.11713.18638..19294...0.1..0.194.1688.0j12......0....1.........0i71j35i39j0i13i30.Deuh8uObWs4