Вторая статья из цикла "Test-Driven Development приложений на Spring Boot" и в этот раз я буду говорить про тестирование доступа к базе данных, важного аспекта интеграционного тестирования. Я расскажу как через тесты определять интерфейс будущего сервиса для доступа к данным, как использовать встраиваемые in-memory базы для тестирования, работать с транзакциями и загружать тестовые данные в базу.

Spring Framework часто приводят как пример Cloud Native фреймворка, созданного для работы в облаке, разработки Twelve-Factor приложений, микросервисов, и одного из самых стабильных, но в то же время инновационных продуктов. Но в этой статье я бы хотел остановиться на еще одной сильной стороне Spring: это его поддержка разработки через тестирование (TDD-руемость?). Не смотря на TDD-руемость, я часто замечал, что в проектах на Spring либо игнорируются некоторые best practices для тестирования, либо изобретаются свои велосипеды, либо вообще не пишутся тесты потому что они "медленные" или "ненадежные". И вот именно о том, как писать быстрые и надежные тесты для приложений на Spring Framework и вести разработку через тестирование я и расскажу. Так что если вы используете Spring (или хотите начать), понимаете что такое вообще тесты (или хотите понять), или думаете что contextLoads это и есть необходимый и достаточный уровень интеграционного тестирования — то будет интересно!

Четкое разделение бизнес логики с другими сквозными задачами является обязательным условием для создания чистого и читабельного кода. И говоря о сквозных задачах я имею ввиду управление транзакциями, безопасность и прочие важные задачи, которые хоть и не относятся к бизнес логике напрямую - но оказывают существенное влияние на работу приложения в целом. В случае "жесткого связывания" основной логики и подобных задач - мы можем получить кучу проблем в случае ошибки последних. АОП, собственно, и нацелено на решение подобных задач.

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

Spring имеет свою собственную структуру АОП, которая концептуально проста для понимания и является отличным решением большинства проблем в корпоративных Java-приложениях. В этой статье мы собираемся рассмотреть магию Spring АОП - со всеми его достоинствами и недостатками. Если у вас вообще нет никакого понимания за данную тему - рекомендую почитать данный материал.

Всем привет! Меня зовут Юрий Лилеков, я работаю в Server Team Badoo. На днях мне попалась довольно интересная статья о новой семантике exactly-once в Apache Kafka, которую я с радостью для вас перевёл.

Данная статья результат поиска некоего каноничного решения организации безопасности доступа к ресурсам в микросервисной архитектуре, построенной в экосистеме Spring. После прочтения десятка статей по данной тематике, к сожалению, не нашел то, что искал. Spring Security оказался одной из самых недопонятых технологий. Основная проблема у всех - изобретение своего велосипеда поверх стандартного функционала Spring Security. Зачастую, данные статьи сопровождаются комментариями никогда так не делать. И у многих, наверно, возникает вопрос, а как собственно можно делать. Ситуацию несколько прояснила официальная документация. Взяв её за основу, я хочу показать, как можно организовать безопасность микросервисов максимально простым и быстрым способом.

В этой статье разберемся, как реализовать обмен сообщениями между Java-микросервисами на Spring с помощью Kafka.

Привет, Хабр!

Я, начинающий Java-разработчик, студент 3 курса, и это - моя первая статья здесь. Я не буду заострять внимание на теории, так как в интернете достаточно статей на эту тему, а сосредоточусь на практике и предложу свое решение. В процессе мы создадим несколько служб, а именно...

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

Во время технических презентаций нашей технологии – платформы быстрой разработки Jmix – мы, как правило, доходим до вопроса архитектуры создаваемых приложений и часто встречаем грусть в глазах разработчиков, когда сообщаем, что создаваемое приложение имеет монолитную архитектуру. Удивительно, но случается, что команды разработки приложений на Delphi или Oraсle EBS непременно заинтересованы в реализации микросервисной архитектуры, отождествляя ее с чем-то очень современным и самым продвинутым. К счастью, хайп вокруг микросервисов постепенно начал замещаться новой информационной повесткой о необходимости рационального использования ресурсов и выбора типа архитектуры приложений на основе компетенций команд разработчиков и масштабов создаваемого решения. В Jmix есть все необходимое, чтобы создавать современные корпоративные информационные системы в рекордные сроки и с минимальными затратами. Мы понимаем, что монолитная архитектура приложений Jmix не может закрыть все кейсы, но мы верим, что для каждой задачи есть подходящий инструмент. Прочитайте перевод статьи из блога Camunda, возможно, она поможет понять какой тип архитектуры подходит для вашего проекта, чтобы сэкономить время, деньги и нервы.

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

Это третья часть серии заметок о реактивном программировании, в которой будет представлено введение в WebFlux - реактивной веб-фреймворк Spring.

Это вторая часть серии заметок о реактивном программировании, в которой представлен обзор Project Reactor, реактивной библиотеки, основанной на спецификации Reactive Streams.

Привет, Хабр. В этой статье я кратко расскажу о деталях реализации микросервисной архитектуры с использованием инструментов, которые предоставляет Spring Cloud на примере простого концепт-пруф приложения.

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