Araya

Добрый день!
Практически каждый день вижу ваши вопросы про разработку календаря.
Если честно, то мне кажется, что вы реализовываете календарь не так как нужно из-за чего позвольте спросить, какого рода календарь вы пишете? Просто, в предыдущих ваших вопросах я видел огромное количество циклов for, которые выводят месяц, год, дату и прочую информацию (високосный год и т.д.). Ощущение будто вы пытаетесь изобрести велосипед. Возможно, что если вы дадите больше информации, то мы сможем дать вам более корректные ответы.
Вот, например, если это десктопное приложение, то например, при использовании JavaFX вы можете применить готовые компоненты для него.
Например,
CalendarFX
Вот, еще пример - https://gist.github.com/james-d/c4a2cf66efecbf3aa362
Вот, еще один компонент - https://github.com/SirGoose3432/javafx-calendar
Вот, еще - https://stackoverflow.com/questions/33281588/creat...

Также обратите внимание, что вместо того, чтобы печатать календарь вручную и самому учитывать все аспекты, вы можете воспользоваться классами в Java, которые предназначены для этих целей.
https://docs.oracle.com/javase/7/docs/api/java/uti...
https://docs.oracle.com/javase/8/docs/api/java/uti...
https://docs.oracle.com/javase/8/docs/api/java/tim...
https://docs.oracle.com/javase/8/docs/api/java/tim...
и т.д.

Если вы хотите распечатать календарь в консоли, то возможно, этот ответ наведет вас на мысль
https://stackoverflow.com/questions/26962388/print...

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

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

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

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

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

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

а) сами, если у вас собственное приложение ака пет=проект(при условии что вы выполнили свою первую и важную цель - устроится на работу
б) более часто - бэк уже выбран за вас, и вы его узнаете на работе, когда вам отдают конечные 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...