Привет!

Поскидывайте в комменты, пожалуйста, литературу по функциональной архитектуре.

Меня в первую очередь интересуют материалы такой же степени детализации/проработки как и Domain Modeling Made Functional, но более "прагматично" - без монад/с примерами на языке не имеющим синтаксической поддержки для них.

Но небольшие посты/презентации тоже скидывайте

#books@ergonomic_code

Привет!

Моя дилемма последней недели.

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

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

Во многом, потому что ФА ни где не описана. Для неё даже на вики странички нет.

#ergo_approach@ergonomic_code #ergo_arch@ergonomic_code

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

Определение с вики:
Определённый набор концепций или шаблонов мышления, включая теории, методы исследования, постулаты и стандарты, в соответствии с которыми осуществляются последующие построения, обобщения и эксперименты в области.

Удивлён, что вариант "Да" лидирует.

На всякий случай: опрос не про "публиковать ли пост", а про "вводить ли новый термин"

У меня де-факто получается какая-то смесь слоёной и функциональной архитектуры с элементами DDD и диаграммой эффектов

Привет!

Позавчера вышел Spring Boot 3.3.0 - не забудьте обновится - с каждым релизом это всё сложнее:)

#spring@ergonomic_code

А 4 дня назад вышел Котлин 2 О_О

#kotlin@ergonomic_code

Привет!

Я ещё почти два года назад назад начал думать в сторону того, что пути эндпоинтов REST/JSON-over-HTTP API надо нарезать исходя из UX-клиентов, а не сущностей/ресурсов.

То есть, допустим, у нас есть пользователи и три эндпоинта:
1. Залогиниться
2. Посмотреть собвтенные данные
3. Посмотреть данные любого юзера для админов

И раньше я делал сам и наблюдал буквально во всех проектах, которые видел, эти эндпоинты замапили бы на:
1. POST /users/login
2. GET /users/profile
3. GET /users/profiles/{id}

А сейчас я бы это зампаил так:
1. POST /public/login
2. GET /user/profile
3. GET /admin/profiles/{id}

И после того, как я отказался от объектно-ориентированной декомпозиции и актуализировался вопрос декомпозции слоя приложения - эта идея заиграла новыми красками - первичную декомпозицию слоя приложения можно делать по UX-ам - считай приложениям

И, например, в TA я это так и сделал - если не считать вспомогательных пакетов infra и platform, в пакте app два подпакета:

1. public - "приложение"-точка входа, для регистрации и логина (по историческим причинам мапится на "/"...)
2. therapist - "приложение"-АРМ терапевта (мапится на "/therapist/")

Ещё есть "приложение"-сисадмина - Spring Boot Actuator (мапится на "/ops/**")

Такая схема, среди прочего ещё и существенно упрощает конфигурацию авторизации

Но это всё была прелюдия.

Я тут наткнулся на оригинальный пост про гексагональную архитектуру (ака порты и адаптеры), а там:

What exactly a port is and isn’t is largely a matter of taste. At the one extreme, every use case could be given its own port, producing hundreds of ports for many applications. Alternatively, one could imagine merging all primary ports and all secondary ports so there are only two ports, a left side and a right side.

Neither extreme appears optimal.

The weather system described in the Known Uses has four natural ports: the weather feed, the administrator, the notified subscribers, the subscriber database. A coffee machine controller has four natural ports: the user, the database containing the recipes and prices, the dispensers, and the coin box. A hospital medication system might have three: one for the nurse, one for the prescription database, and one for the computer-controller medication dispensers.

It doesn’t appear that there is any particular damage in choosing the “wrong” number of ports, so that remains a matter of intuition. My selection tends to favor a small number, two, three or four ports, as described above and in the Known Uses.

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

Ни один из крайних вариантов не кажется оптимальным.

Система прогнозирования погоды, описанная в "Известных вариантах использования", имеет четыре естественных порта: канал прогноза погоды, администратор, уведомленные подписчики, база данных подписчиков. Контроллер кофемашины имеет четыре естественных порта: пользователь, база данных, содержащая рецепты и цены, дозаторы и ящик для монет. Больничная система выдачи лекарств может состоять из трех компонентов: один для медсестры, один для базы данных рецептов и один для диспенсеров лекарств с компьютерным управлением.

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

И я в этом тексте вижу те же самые приложения (в "левых"/основных портах у Кокбёрна), что и у себя.

В общем советую подумать в сторону того, сколько UX-ов есть у ваших (монолитных) бакендов и отражено ли это в вашей архитектуре

#design@ergonomic_code #rest_api@ergonomic_code #hexagonal_architecture@ergonomic_code #trainer_advisor@ergonomic_code

Привет!

А вы знали, что оказывается есть стандарт на тела ошибочных JSON-ответов - Problem Details for HTTP APIs и для него в 6-ой Spring завезли поддержку?

#http_api@ergonomic_code #spring@ergonomic_code #error_handling@ergonomic_code

Привет!

Оу-оу-оу! Да чтош за весна релизов-то? Вышел Jackson 3.0

Но не Jackson сегодня гвоздь программы.

Я накатал микропост о том как стремление улучшить HTTP API проекта (который был "готов" 1.5 недели назад) привело к улучшению дизайна его модели.

#http_api@ergonomic_code #rest_api@ergonomic_code #project_mariotte@ergonomic_code

Привет!

Посмотрел интервью с Кокбёрном (мужиком, который придумал Гексагональную архитектуру).

И там на 27ой минуте есть интересный момент - кажется, по Кокбёрну порты не обязательно оформлять в виде public interface ISomethingGateway - для него любая функция является интерфейсом. А важна лишь семантика этой функции - чтобы она была определена в терминах домена, а не низлежащей технологии.
Но я не уверен, что правильно понял - там зубодробительная смесь не родного для меня языка, неоднозначной терминологии, разговорной речи и паршивых иллюстраций.

И ещё в этом же видосе он порекомендовал сайт о ГА - https://jmgarridopaz.github.io/

#talks@ergonomic_code #guideline@ergonomic_code

Привет!

Сегодня решил поделиться полезняшкой - git worktree.

Эта команда позволяет добавить рабочую директорию для существующего гит репоза (ещё одну директорию с исходниками без собственной директории .git).

Это позволяет даже для больших проектов иметь пачку "репозов" и быстро переключаться между задачами. У меня как правило для каждого проекта есть пачка рабочих директорий:
1) main - для текущей задачи
2) hot-fix - для хот фиксов
3) по директории на каждого разработчика - для ревью
4) плюс частенько завожу ещё отдельные директории для различных экспериментов с кодовой базой.

#tools@ergonomic_code #git@ergonomic_code

А ещё в Сибирь наконец-то пришло лето:)

Привет!

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

В связи с чем у меня возник вопрос - а их сейчас вообще хоть кто-то рисует?

Привет!

Не прошло и месяца и я сделал это!

Представляю вашему вниманию Project Mariotte - минималистичный и подробно задокументированный демопроект Эргономичного подхода на примере сервиса бронирования номеров в отелях.

У меня есть идея ещё пары-тройки проектов, с демонстрацией более развесистой бизнес-логики и более сложными взаимодействиями с инфраструктурой - надеюсь на горизонте пары лет их я тоже сделаю:)

#project_mariotte@ergonomic_code #ergo_approach@ergonomic_code #spring@ergonomic_code #tdd@ergonomic_code #functional_architecture@ergonomic_code #dop@ergonomic_code #immutable_domain_model@ergonomic_code

Привет!

Я в Project Mariotte сделал страшное - перешёл на MockMvc.

Изначальная мотивация была в том, чтобы сэкономить секунду на запуске Tomcat.

Потом выяснилось, что инициализация RestAssured занимает ещё секунду, которую тоже можно сэкономить

Но последним аргументом стало то, что со WebTestClient можно переехать на работу через HTTP за три четыре простых шага.

И это навело меня на мысли об эволюции ЭП от сложного к простому за последние 4 года.

В конце 19-ого - начале 20-ого года можно было сказать, что ЭП = модульный монолит + тесты без моков + ДДД + чистая архитектура + railway-oriented programming на монадах.

И на тот момент, это всё (на мой взгляд) были маргинальные идеи, не имеющие широкого распространения.

Но за прошедшие 4 года, они все если не вошли, то сильно приблизились к мейнстриму, на мой взгляд.

А я с ЭП за эти же 4 года то ли ушёл вперёд, то ли откатился назад:

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

2. В тестировании добавилось разрешение на использование моков для симуляции ошибок инфраструктуры и для дорогой инфраструктуры. И свеженькое разрешение на использование MockMvc, при условии, что код самих клиентв (тест-кейсов) на него не завязан.

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

4. Чистую архитектуру я заменил на тщательное проектирование интерфейсов;

5. ROP на монадах, наконец, я заменил на Guard clause.

И при этом Эргономичный подход остаётся совместимым со всеми этими идеями там, где это надо:

1. Цитадель оказалась плохой затеей? Затолкать её обратно в монолит - вообще не проблема;

2. Тестов на моках стало слишком много или появилось слишком много багов в обработке ошибок? Поменять моки на стабы - уже сложнее, но тоже вполне решаемая задача;

3. В проекте появилась сложная предметная область и/или эксперт по ней? Перейти на ограниченные контексты и агрегаты на базе инвариантов - без проблем, вся инфраструктура и структура кодовой базы готовы;

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

5. В проекте появилась потребность на лету собирать пайплайны? Обернуть имеющиеся вызовы эффективных методов в монады не составит труда.

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

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

Теперь Эргономичный подход стал глотком свежего воздуха для тех, кто устал от поисков стороны, с которой подойти к ДДД, церемоний чистой архитектуры и сложностей объяснения монад простым смертным.

В общем, покой нам только снится:)

#ergo_approach@ergonomic_code #project_mariotte@ergonomic_code #tdd@ergonomic_code #ergo_testing@ergonomic_code #mocks@ergonomic_code #clean_architecture@ergonomic_code #functional_architecture@ergonomic_code #ddd@ergonomic_code #rop@ergonomic_code

После Project Mariotte я перенёс подход с MockMVC на другой (закрытый) проект и словил там проблему - по дефолту настройки секьюрити не подтянутся.

Для того чтобы их прикрутить надо:
1. Не забыть добавить зависимость testImplementation("org.springframework.security:spring-security-test")
2. Донастроить webTestClient:

         client = MockMvcWebTestClient
            .bindToApplicationContext(applicationContext)
            .apply(springSecurity(FilterChainProxy(securityFilterChain)))
            .configureClient()
            .defaultHeader("Content-Type", "application/json")
            .build()

Возможно там где-то дальше ещё какие-то грабли есть, но меня утешает мысль, что вернуться к тестам через HTTP можно будет лёгким движением руки

#ergo_testing@ergonomic_code #tdd@ergonomic_code #mockmvc@ergonomic_code #springsecurity@ergonomic_code #webtestclient@ergonomic_code

Привет!

Я посмотрел Migrating from (Spring Data) JPA to Spring Data JDBC.
И пересмотрел Меняем Spring Data JPA на Spring Data JDBC! (на который уже писал своё фи).

Удивительно, насколько эти доклады об одном и том же разные:
1. Дженс начинает с тестов и выделяет для них целый слайд. Андрей между делом упоминает их в конце доклада
2. Дженс топит за то, чтобы делать это очень аккуратно и постепенно и рассказывает про любопытную методику больших рефакторингов. А Андрей шарашит с распахнутым забралом и даже без тестов
3. Дженс практически ~50% доклада (~20 минут из ~40) посвящает перепроектированию модели данных. Андрей посвящает этому ~3% (~2 минуты из ~60)
4. Естественно, Дженс чморит JPA, а Андей - SDJ

Зато, оба доклада раскрывают тему генерации id 🤷‍♂️ И я до сих пор не понимаю, чем default nextval('seq') плох, раз уж generated always as identity не подходит

И эта разница навела меня на новый аргумент против jpa за sdj.

При разработке приложения на базе JPA основными сложностями будут изучить саму JPA, потом накастовать аннотаций, чтобы она делала то, что надо, а через полгода угадывать как это всё будет работать. Это всё - привнесённая сложность (Accidental complexity), которую можно и не привносить.

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

И хотя, теоретически, JPA позволяет так же выполнить декомпозицию модели, она не обязывает это делать.
В результате в приложениях на JPA на декомпозицию предметной области забивают и в ответ получают Big Ball of Mud. Так произошло в 100% проектах на JPA, которые я видел.

Проектирование агрегатов - действительно сложная тема и по ней написано много хороших книг. Но с ними со всеми есть одна проблема - они полагаются на экспертов предметной области.

И хотя это лучший способ выполнить декомпозицию предметной области, у него есть недостатки:
1. Эксперты предметной области зачастую недоступны в принципе.
2. А когда доступны - извлечение формальной модели из головы другого человека средствами естественного (неформализованного) языка - это в целом задача на уровне "мишшн импоссбл", а для многих технических специалистов просто за гранью понимания.

Из-за этого проектирование агрегатов зачастую хромает на обе ноги.

Поэтому я сейчас использую более технический подход к проектированию агрегатов. Об этом подходе надо написать отдельный пост, но если вкратце, он выглядит так:
1. Спроектировать ЕР модель, особое внимание уделить слабым сущностям
1.1 Признаки слабой сущности:
1.1.1 её жизненный цикл ограничен жизненным циклом другой сущности - позиция заказа не может существовать без заказа, номер не может существовать без отеля
1.1.2 она упоминается всегда в контексте другой сущности - вторая строчка заказа такого-то, номер 215 отеля такого-то
2. Все стержневые сущности (со слабыми и без них) считаются корнями агрегатов
3. Провести транзакционный анализ - в идеале в рамках одной транзакции должен меняться один агрегат и меняться целиком. Если это не так - что-то надо объединить, а что-то разделить.

Этот подход базируется на косвенных признаках (жизненный цикл сущностей и UI), поэтому он, скорее всего, даст менее точную модель, чем построение модели вместе с экспертом. Но он не требует эксперта и общения с ним. И лучше так, чем никак.

Ещё ссылки по теме:
1. Нотация описания неизменяемой модели данных (+ Ответы на вопросы по Эргономичной нотации ER-модели)
2. Агрегаты
3. Рациональный подход к декомпозиции систем на модули или микросервисы

В общем, инвестируйте свой интеллект в решение присущей сложности задачи, а не привнесённой:)

#why_sdj@ergonomic_code #whynojpa@ergonomic_code #ddd@ergonomic_code #spring_data_jdbc@ergonomic_code #jpa@ergonomic_code