Проектирование и рефакторинг *

Современный Spring Boot, это пожалуй лучшее, что есть в экосистеме Java на сегодняшний момент. Особенно если речь идет о Spring модулите.

Проблема заключается в том что в интеренете, нет ни одного реального примера Spring модулита, да и в принципе кроме Pet Clinic, нет ни одного проекта близкого к реальным задачам. Поэтому, команды зачастую, каждый раз заново придумывают эту архитектуру заново, наступая на одни и те же грабли.

На практике это обычно означает:

Одна БД;

Для каждого модуля своя схема;

Один Git репо;

Каждый модуль можно собирать и тестировать отдельно независимо друг от друга;

Для миграции используется liquibase или flyaway;

Обычно Gradle лучше подходит под модулит;

Деплой одной поставкой/релизом;

Некоторые модули взаимодействуют друг с другом с помощью REST API, а некоторые используют брокер сообщений;

Все это работает в одном неймспейсе Kubernetes если он выбран в качестве целевой платформы;

          +-----------------------------+
          |       Object Storage         |
          |   (e.g., AWS S3, MinIO)      |
          +-----------------------------+
                        |
                        v
+-----------------------------------------------------------+
|                  Kubernetes Namespace                     |
|                                                           |
|  +-----------------------------------------------------+  |
|  |                   API Gateway                       |  |
|  |           (Spring Cloud Gateway)                    |  |
|  +-----------------------------------------------------+  |
|                 ^        ^        ^        ^              |
|                 |        |        |        |              |
|  +----------------+     +----------------+     +-------+  |
|  | Microservice 1 |<--->| Microservice 2 |<--->|  ...  |  |
|  | (REST & Kafka) |     | (Kafka Only)  |      +-------+  |
|  +----------------+     +----------------+                |
|                                                           |
|  +----------------+     +----------------+                |
|  | Microservice 3 |<--->| Microservice 4 |                |
|  | (REST Only)    |     | (Kafka Only)   |                |
|  +----------------+     +----------------+                |
|                                                           |
|  +----------------+     +----------------+                |
|  | Microservice 5 |<--->| Microservice 6 |                |
|  | (Kafka Only)   |     | (REST & Kafka) |                |
|  +----------------+     +----------------+                |
|                                                           |
|  +----------------+     +----------------+                |
|  | Microservice 7 |<--->| Microservice 8 |                |
|  | (REST Only)    |     | (Kafka Only)   |                |
|  +----------------+     +----------------+                |
|                 ^        ^        ^        ^              |
|                 |        |        |        |              |
|  +-----------------------------------------------------+  |
|  |                     Kafka Cluster                    | |
|  |   (Apache Kafka / Event Bus for Async Communication) | |
|  +-----------------------------------------------------+  |
|                                                           |
|  +-----------------------------------------------------+  |
|  |              PostgreSQL HA Database                  | |
|  |   (Primary + Standby Nodes for Data Persistence)     | |
|  +-----------------------------------------------------+  |
|                                                           |
+-----------------------------------------------------------+

Выводим Ситника на чистую воду

Топ перлов:

• Sync-engine избавляет от однотипного кода по загрузке данных .. он заставляет вас проверять isLoading === true и рисовать крутилку.

• Во всех sync-engine используются нормальные стейт менеджеры .. например, nanostore (см. видео с разбором этой библиотеки).

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

• CRDT - это просто лог операций (лог операций - это CmRDT и OT, CvRDT даже близко не лог).

• Работать с IndexedDB через скомпилированный под WASM SQLite быстрее, чем напрямую работать с IndexedDB (разве что, если руки заточены под обнимашки).

Упомянутые ссылки:

• Local-First база данных CRUS-DB

• Децентрализованное хранилище секретов

• Реактивный ToDoMVC без sync-engine

• $mol_wire в React

• Протоколы запросов HARP vs GQL

• Легковесный язык разметки MarkedText

• Натальная травматология фронтенда

• Гильдия Гипер Дев

Копилка благодарностей

VK (видео)

📦 API for Any(thing) 2

☝️Возможно ли создать интерфейс для получения любого объекта одинаковым способом? 

Библиотека работает на продакшене в приложениях:
Энергия
NFC Tool
КубГТУ

Во второй части доклада практическая реализация 💡

Хабр
Medium
GitHub

El-Machine.com Apps 🤖

Теория:
Часть 1

YouTube (видео)

📦 API for Any(thing) 

☝️Возможно ли создать интерфейс для получения любого объекта одинаковым способом? 

Продолжаю развивать свою идею архитектуры для 100% инкасуляции, разбития на модули и тестирования всего слоя Model

Хабр
Medium
GitHub

Первая часть доклада теоретическая. В поисках API для любого (Any) объекта

Во второй части доклада практическая реализация 💡

Поделитесь мыслями:
Что думаете про декларативны подход? Описываю результат и получаю нужный объект

Часть 2

Луковая архитектура, и как не заплакать в процессе погружения. Запись митапа

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

На внутреннем митапе рассказали, как устроена луковая архитектура, границах применимости и о том, как с пользой начать использовать её в разработке. Затронули теорию и практику: рассмотрели специфику луковой архитектуры на примере конкретного pet-проекта. 

Коснулись CQS-CQRS дизайн-паттерна, рассмотрели пайплайн MediatR, реализацию валидаций с FluentValidation, маппинг через AutoMapper, и как организовать сущности доменного слоя. 

Остановились на первых двух слоях — Domain.Core и Application. Об устройстве других слоев (Infrastructure и Web API) поговорим на будущих митапах.

Посмотреть запись митапа можно на YouTube или RUTUBE.

P.S. Это запись внутреннего митапа ИТ-команды Сравни — публикуем эпизоды без NDA, но (надеемся) с пользой для внешнего сообщества.

***

Узнавать о выходе наших новых материалов (митапов, лекций, статей), помимо Хабра, можно в тг-канале инженерного сообщества Сравни. 

Всем привет!

Расскажу про один поучительный факап из моей практики.

Более 10 лет назад. Стартап. Я на тот момент и СТО, и разработчик в одном лице. Есть задача, в целом понятная. Декомопозирую на микросервисы и подзадачи, начинаю пилить. Дохожу до XML binding - преобразования XML в объекты. Тогда API в основном были XML. Решил погуглить - что есть на рынке. Кроме известного многим JAXB нахожу JiXB. Не известный тогда, тихо умерший сейчас. Читаю описание и нахожу бенчмарк, показывающий что он ... скажем в 1.5 раза быстрее JAXB. Думаю - о, круто, надо брать. Начинаю прикручивать к Spring. Наталкиваюсь на кучу подводных камней - это не работает, документации мало, ошибки не информативные и не гуглятся. В общем убил неделю на прикручивание к проекту одной библиотеки. В итоге все заработало, конечно. А проект не был доведен до работающего состояния и так и не взлетел.

Итоги. До сих пор стыдно за такое решение по следующим причинам:

1. речь про стартап, т.е. нужно быстро создать работающий прототип, а не исследовать новые технологии

2. преждевременная оптимизация - данных по требуемому RPS и доступному железу на тот момент у меня не было. Нагрузочное тестирование не проводилось. Стал бы JAXB узким местом - не факт

3. использовать в промышленной разработке не доказавшие свою зрелость библиотеки - это риск. Очень важны сообщество и работающие без бубна связки, например, Spring+JAXB. А риск должен быть оправдан, а еще должен быть план отката. Не взлетело, сыро - откатываемся на надежный вариант

Всем привет!

Вопрос - где применяется подход DDD?
Аналитика, разработка, тестирование. Конечно архитектура АС, с нее все начинается.
Но это еще не все.
Есть такой класс систем как Data Warehouse (DWH) или аналитическое хранилище данных. В это хранилище попадают данные из всех бизнес-сервисов компании для дальнейшего анализа. Т.об. мы разделяем оперативную БД и аналитическую, снимая лишнюю нагрузку с оперативной БД. Особенность Data Warehouse - технологии обработки и хранения данных отличаются от используемых в системах оперативной обработки данных. Hadoop, Greenplum, ClickHouse... А значит нужны специалисты, которые подготовят хранилище под ваши данные и настроят синхронизацию с оперативной БД. Но эти специалисты не знают ваш домен, в отличие от команды. Плюс они часто становятся "бутылочным горлышком". Плюс структура данных постоянно меняется...
Что делать?
Data Warehouse специалисты готовят инфраструктуру, а за подготовку и синхронизацию данных, актуальность их структуры и способ предоставления этих данных потребителям отвечает бизнес команда. Это же ее bounded context. Подход называется Data Mesh. Вот неплохая статья на эту тему.
P.S. На самом деле DevOps в своем идеальном виде о том же - DevOps инженеры готовят инфраструктуру, а за сборку и деплой отвечает команда.

Всем привет!

Поговорим снова о микросервисах. Я уже писал, почему не стоит делать слишком мелкие микросервисы https://t.me/javaKotlinDevOps/305 (блог в телеге я стал вести сильно раньше, чем на Хабре)
Но встает закономерный вопрос - "сколько вешать в граммах", в смысле - а какого размера должны быть микросервисы?
Обозначим нижний и верхний предел, а для этого придется вспомнить DDD.

Для начала рассмотрим понятие ограниченного контекста (bounded context). Это связанный набор сущностей из реального мира, для наименования которых используется "единый язык" (ubiquitous language) - непротиворечивый набор терминов. Эти сущности описываются в аналитике, тест-кейсах и превращаются в классы в нашем сервисе и в таблицы в БД. Контекстом как правило занимается одна команда - так проще всего поддерживать "единый язык". И за микросервис тоже должна отвечать одна команда. Т.е. ограниченный контекст - это отличный кандидат на микросервис. Но при этом у одной команды может быть несколько микросервисов. И контекст может быть достаточно большим. Т.е. у нас есть верхняя граница микросервиса.

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

Всем привет!

Недавно посмотрел интересное видео про управление техдолгом https://youtu.be/pvZDcytPU3w

На самом деле видео не про управление техдолгом в целом. Там нет архитектурного техдолга, технологического. Оно про техдолг, возникающий при реализации конкретной фичи - когда появляется TODO в коде.

Речь идет о извечной проблеме разработчика - "сделать все идеально". Но идеально может потребовать дни или даже недели. А у нас Agile, спринты в 2 недели, бизнес ждет свою фичу.
Что предлагается:

1. не надеяться, что декомпозиция задачи на планировании будет идеальной

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

3. расставить по коду подробные TODO, рассказать команде что сделано, а что нет и почему, и влить доработку. Т.об. мы гарантировано получаем большую прозрачность. А если правильно удалось определить, что блокер для команды - еще и лучший Lead Time.

4. далее некий робот сканирует код, находит TODO и делает из них таски в вашем трекере

5. таски будут оценены на очередном планировании и взяты в работу, возможно другим разработчиком

   Самое интересное - для одной и той же задачи пункты 1-5 могут повторяться. Наверное, если это происходит в 5-й раз - стоит детальнее взглянуть на задачу. Похоже она сильно влияет на архитектуру.

   Итого - идея мне нравится!

Всем привет!

TDD конечно крутая штука в плане правильного проектирования сервиса. Правильное проектирование - имеется в виду получить публичное Java API, удобное для использования, если не с первого раза, то с меньшим количеством итераций.

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

Что там может быть:

• входные данные -> выходные данные

• обработка возможных исключений

• повторный запуск: идемпотентность, докат или ошибка

• параллельный запуск

• поведение при различных значениях настроек

• поведение при различных настройках кодировки, языка, часового пояса, файловой системы

• эффекты из-за отсутствия транзакционности (там где ее нет) ...

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

  По сути это формализация процесса проектирования через запись в виде тестовых кейсов. И есть подозрение, что наличие перед глазами набора кейсов сделает процесс написания кода станет более осмысленным.

Всем привет! 

Меня зовут Дмитрий. В ИТ я сравнительно недавно, всего 25 лет, из которых последние 22 в банковском секторе (ЦБ, ВТБ, Банк ДОМ.РФ). И за это время я стал смотреть по-другому на многие привычные вещи. 

Вот недавно я подумал, что русская народная сказка про царевну-лягушку, это не только про неё. Вы помните: "... нелегко с Кощеем сладить: его смерть ☠️ на конце иглы, та игла в яйце 🥚, яйцо в утке 🦆, утка в зайце 🐇, тот заяц сидит в каменном сундуке 🗃️, а сундук стоит на высоком дубу 🌳, и тот дуб Кощей Бессмертный, как свой глаз, бережёт...". 
Будто бы это не и сказка вовсе, а лаконичное описание архитектуры развертывания. Словно «игла» это приложение 🤖, со встроенной killer-feature, при падении которой происходит необратимое последствие - смерть Кощея. Если перевести на бизнесовый - уход ключевого клиента.

А сколько такого в жизни! И Кощей был побеждён лишь потому, что с гео-распределённым решением заморачиваться не стал, или не смог. 🙈
То есть, в переводе на ИТ-шный, намек этой сказки может выглядеть так: хотите чтобы Ваши сервисы жили вечно - не поступайтесь вопросами надежности ИТ архитектуры. 🏛️

А раньше эта сказка мне казалась просто сказкой ... ☀️

Разбор доклада Артёма Арутюняна про Архитектуру и Реактивное Программирование

Топ перлов:

• Реактивное программирование - это программирование на событиях.

• Реактивность нужна между модулями, а внутри - не нужна.

• По одному лишь графу связей можно понять правильно произведена декомпозиция или нет.

Мета: Копилка благодарностей, Новости, Форум

Всем привет!

Попробую немного развить тему с законом Конвея из предыдущего поста. Я достаточно много раз за свою карьеру в разработке сталкивался с упоминанием данного закона. Уже не вспомню где конкретно, но у меня осталось стойкое впечатление, что отношение к нему было как к неизбежности, с которой нужно бороться. Способы борьбы можно вспомнить такие:

• корпоративные архитекторы, выравнивающие архитектурные шаблоны

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

• техрадар как способ ограничить технологический стек

• единые практики найма и онбординга

• корпоративная модель данных — как антипод принципа DDD, когда существует некая общая для организации единственно верная доменная модель...

Так вот — что мне нравится в парадигме DDD, что она говорит — не надо бороться, надо принять как данность, расслабиться и получать удовольствие от своего ограниченного контекста). Ремарка – речь про применение закона в проектировании ПО.

Всем привет!

Разработка ПО - очень динамичная сфера. Мэйнфреймы, ассемблер, CSV, RDBMS, C, Delphi, Java, REST, MQ, git, DevOps, Docker, k8s, Kafka, noSQL, microservices, reactive programming, DataLake, GitOps, ChatGPT...
Но есть вещи, которые не меняются. 1967 год, сформулирован закон Конвея - Любая организация, которая разрабатывает систему (в широком смысле), вынуждена создавать проекты, структуры которых являются копией структуры связей организации. Причем если верить wiki, а в данном случае IMHO это можно делать, закон был доказан, видимо на исследовании реальных компаний.
Так вот, читаю сейчас одну интересную книгу про внедрение DDD - Domain Driven Development, 2022 года выпуска. В главе про внедрение вижу такой совет - начать с того, что определить бизнесовые поддомены в компании, на основании которых будут строится ограниченные контексты - одна из ключевых сущностей DDD. Как их проще всего определить? Рекомендуется посмотреть на структуру организации. Закон Конвея в DDD)

P.S. Интересно и то, что в 1967 году разработка как отрасль уже достигла уровня, позволяющего формулировать определенные принципы.

«Архитектура программного обеспечения» — обновлённый курс Яндекс Практикума

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

Основное про курс:

• Много практики: по окончанию курса вы сможете добавить в портфолио 11 проектов.

• Качественная обратная связь: все работы будут проверять специалисты с опытом создания распределённой и высоконагруженной архитектуры.

• Диплом о профессиональной переподготовке или сертификат по окончанию обучения.

Вы научитесь:

• Проектировать и реализовывать микросервисные архитектуры, управлять ими.

• Применять паттерны масштабируемости, устойчивости и взаимодействия между сервисами.

• Развёртывать приложения в облачных средах с помощью Kubernetes, Docker и Terraform, управлять ими.

• Выстраивать стратегии миграции в облако и управлять большими объёмами данных.

• Применять репликацию, шардинг и обработку данных в реальном времени.

• Создавать решения для мониторинга с помощью Prometheus и Grafana.

• Применять лучшие практики в области безопасности, включая управление идентификацией и доступом (IAM).

• Интегрировать функции безопасности в дизайн и развёртывание приложений.

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

Ближайший старт обучения — 27 июня и 25 июля.

Узнать о курсе подробнее и начать учиться бесплатно →

Monolith-first подход

Из опыта я глубоко убеждён, что в 99% случаем начинать создание новой системы лучше с монолита. Особенно если это абсолютно новый продукт, которому только предстоит выйти на рынок.

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

В такой ситуации вы начнёте спокойно делить монолит на микросервисы. Выделите связанные контексты, начнёте вынос кода и миграцию баз данных. Это стандартная история IT-мира. У нас был монолит, но мы выросли и мигрировали на микросервисы.

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

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

Больше интересного про жизнь в IT у меня в ТГ

Шаблон декомпозиции ModelView Fractal

Каждый ModelView выступает в роли модели/контроллера для ведомых ModelView и в качестве отображения для владеющего ModelView. Часть логики может выноситься как в чистые Model, так и в чистые View, которые являются лишь вырожденными случаями ModelView.

$my_user_list $my_view
	- \Owner ModelView
	users? /$my_user
	kids /
		<= Row*0 $my_user_row
			user <= user*

$my_user_row $my_card
	- \Having ModevView
	user $my_user
		avatar => image
		nickname => message

$my_card $my_view
	- \View not Model
	kids /
		<= Image $my_image
			uri <= image \about:blank
		<= Message $my_text
			text <= message \
	
$my_user $my_model
	- \Model not View
	avatar? \
	nickname? \

✅ Каждый ModelView полностью контролирует внутренние ModelView и ничего не знает про внешние.
✅ Любой ModelView может шариться между разными другими ModelView на любом уровне композиции.
✅ Изменение интерфейса ModelView требует изменения только лишь его владельцев.
✅ Фрактальная структура легко масштабируется на приложения любого размера.

Шаблон декомпозиции Model-View-Presenter

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

// Presenter
class User_preview {
	user: User
	card = new Card({
		image: ()=> this.user.avatar,
		message: ()=> this.user.nickname,
		color: ()=> this.user.skin.color,
		click: ()=> this.skin_change(),
	})
	skin_change() {
		this.user.skin = Skin.random()
	}
}

// View
<div class="Card" onclick={click} style={{ background: color }}>
	<img src={ image } />
	<p>{ message }</p>
</div>

// Model
class User extends Model {
	avatar: string
	nickname: string
	skin: Skin
}

✅ Легко добавлять новые отображения, не меняя модели. И наоборот.
✅ Изменение интерфесов модели или отображения требует изменения только лишь презентеров.
❌ Трёх слоёв слишком мало на больших масштабах.
❌ Для использования состояния одного презентера из другого необходимо искусственное вынесение его в модели.

Шаблон декомпозиции Model-View-Controller

Контроллер создаёт отображение, и говорит ему с какой моделью работать. Так же он обрабатывает все команды от пользователя, и управляет своими подопечными.

// Controller
class Users_resource {
	GET() {
		return User.all.map( user_brief )
	}
}

// View
function user_brief( user: User ) {
	return {
		id: user.guid,
		name: user.passport.name_full,
	}
}

// Model
class User {
	
	static all = [] as User[]
	
	guid: GUID
	passports: Passport[]
	resumes: Resume[]
	
	get passport() {
		return this.passports[0]
	}
	
}

✅ Отображение может использовать произвольные модели с тем же интерфейсом.
✅ Легко добавлять новые отображения, не меняя модели. И наоборот.
❌ Для отображения разных типов моделей необходимо дублировать код отображения.
❌ Изменение интерфейса модели требует обновления всех использующих её отображений и контроллеров.
❌ Трёх слоёв слишком мало на больших масштабах.

Шаблон декомпозиции Model-View-ViewModel

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

// View
<li class="User_card" model="User_card_model">
	<img src={ image } />
	<p>{ message }</p>
</li>

// ViewModel
class User_card_model {
	user = User.current
	get image() {
		return this.user.avatar
	}
	get message() {
		return this.user.nickname
	}
}

// Model
class User {
	avatar: string
	nickname: string
	static current = new User
}

✅ Отображение может использовать произвольные вьюмодели.
✅ Легко добавлять новые отображения, не меняя ни модели, ни вьюмодели.
✅ Изменение интерфейса модели или отображения требует изменения только лишь вьюмодели.
✅ Одну и ту же вьюмодель можно шарить между несколькими отображениями.
❌ Для отображения разных моделей необходимо дублировать код отображения и вьюмодели.
❌ Трёх слоёв слишком мало на больших масштабах.