Araya

человек вообще ни у чом не уиноват.
просто в компании не выстроены (или не правильно выстроены) бизнес-процессы.

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

Я начинающий фронтенд разработчик

Правильный вариант ответа:

Здравствуйте, я джун|миддл который работает год в компании фронтом, умею отлично во фронт, и хотелось бы углубиться в бэк | название языка

В попытке усидеть на всех стульях разом, вы вряд ли сдвинетесь с места. Если вы фронт, то бэк вы выбираете:

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

Приведу аналогию: вы начинающий водитель, ваша задача - научиться водить, дабы уверенно себя чувствовать в городе(выехать и не создавать критической ситуации).

Вы: я не поеду в город, пока не выучу досконально работу двигателя, трансмиссии.

Вывод: не лезьте в бэк, не забивайте голову лишний информацией - её и так много. Сперва уложите в правильном порядке один стэк,устройтесь на работу - второй стэк.

Добрый день.
Предположу, что у вас все-таки реализован не микросервисный монолит, а монолитная архитектура. Вы лишь разделили монолитное приложение на модули и подключили их в gradle. С другой стороны - а нужен ли вам микросервисный монолит или микросервис вообще, если приложение довольно маленькое и им пользуются всего 40 человек.
Если речь идет просто о взаимодействии модулей монолитного приложения, то в соответствующем gradle файле модуля подключаете нужный модуль и импортируете нужные сервисы, классы и т.д.
Главное обратите внимание, чтобы не было циклической зависимости, которая у вас указана тут:

Circular dependency between the following tasks:
:amocrm:compileJava
\--- :datadeal:compileJava
     \--- :amocrm:compileJava (*)

Информация по теме -
https://reflectoring.io/spring-boot-gradle-multi-m...
https://spring.io/guides/gs/multi-module/
Циклическая зависимость возникает, когда модуль А ссылается на модуль В, а модул В ссылается на модуль А. Ни gradle, ни maven не могут решить эту проблему, так как для сборки одного модуля нужен другой модуль, а для другого первый. Также это говорит о том, что возможно проект был несовсем корректно разделен на модули. Можно попробовать создать модуль C, и вынести общие для модулей A & B классы в него. А затем добавить зависимость модуля A от C, а модуля B тоже от C. Таким образом циклической зависимости не будет. Также обратите внимание на рекомендации по организации структуры Spring приложения, которая указана в оф. документации на их сайте.

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

Если уж вам понадобилось делить проект на микросервисы, то как по мне лучше реализовать полноценную микросервисную архитектуру через API Gateway. Соответственно, связать модули через REST. Тут уже понадобится Spring Cloud API Gateway, Spring Cloud Netflix Eureka Client & Server и т.д.

Возможно, что есть подводные камни, о которых я не знаю. Надеюсь, что коллеги поопытнее более подробно ответят на данный вопрос.
А так вот, небольшая статья по данной тематике: https://habr.com/ru/post/496934/
Вдруг, вам будет интересно - небольшой вводный курс по Spring Cloud, Eureka, Zulu и т.д. - https://www.udemy.com/course/spring-boot-microserv...