Привет!

Узнал новый для меня термин в области архитектуры систем - Цитадель. И он явно лучше подходит для того, что я имел ввиду, когда говорил о Микроядерной архитектуре

#posts@ergonomic_code

Привет!

Я тут проснулся с мыслю - а вам не кажется, что Микросервисная, Гексагональня и Кричащая архитектуры - это всё про разное? И один проект может соответствовать всем трём сразу?

Привет!

Решил попробовать завести группу, посвящённую применению основных идей ЭП (модульные монолиты, неизменяемую модель данных, функциональную архитектуру, интеграционные тесты, outside in TDD, data-oriented programming) на практике.

Задумка такая, что столкнувшись с проблемой в собственной практике вы приносите её в группу и остальные члены группы (как минимум я), накидывают идеи и соображения по решению.

Присоединяйтесь, будет полезно:)

P.S. Буду благодарен за репост:)

И опубликовал очередной кусочек описания тестирования Trainer Advisor - формирование фикстурных объектов и их вставка в БД.

Там из 34К знаков 14К - код, почти половина:).

P.s. сбросьте кэш браузера, чтобы подтянуть css с выделеним строк в некоторых из сниппетов

#trainer_advisor@ergonomic_code #ergo_testing@ergonomic_code

Привет!

Забрёл сегодня в блог анкл Боба, там наткнулся на древний пост, а там:

OO is not about state.
Objects are not data structures. Objects may use data structures; but the manner in which those data structures are used or contained is hidden. This is why data fields are private. From the outside looking in you cannot see any state. All you can see are functions. Therefore Objects are about functions not about state.
When objects are used as data structures it is a design smell; and it always has been. When tools like Hibernate call themselves object-relational mappers, they are incorrect. ORMs don’t map relational data to objects; they map relational data to data structures. Those data structures are not objects.
Objects are bags of functions, not bags of data.

#posts@ergonomic_code #oop@ergonomic_code

Привет!

Дочитал Code That Fits in Your Head.
И хотя там есть нюансики (использование фейков БД, складирование всего кода в одной директории 🤯🤦‍♂️), автор топит за outside in tdd и функциональную архитектуру - рекомендую. Особенно молодым разработчиком.

Плюс практически одновременно досмотрел доклад Влашина Moving IO to the edges of your app: Functional Core, Imperative Shell - в целом, наверное, ничего прорывного в докладе нет, но если вы (как и я) ещё не уверены, что знаете на 100% как её применять - можно посмотреть. Там примеры на C# и никаких монад.

#books@ergonomic_code #talks@ergonomic_code #functional_architecture@ergonomic_code

Привет!

Посмотрел Build Abstractions Not Illusions.

Любопытная мысль оттуда:
> лёгкий тест на то, является ли абстракцией то, что вы сделали:
Абстракция должна вводить новую терминологию.

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

#talks@ergonomic_code #design@ergonomic_code

Привет!

Второй или третий раз смотрю де-факто один и тот же доклад про ТДД и не устаю его рекомендовать - в этот раз по мотивам доклада у меня снова родилась пачка мыслей.

Мысль №1
В докладе мужик привёл пару определений:
> Падение юнит-теста подразумевает сбой ровно в одном юните (методе, классе, модуле, пакете)
> Падение девелоперского теста подразумевает ошибку в последнем изменении кода

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

И это прям хорошо легло на мой свежий опыт:
1. В Trainer Advisor у меня примерно 3-4 теста на HTTP-эндпоинт. И ~95% - работают либо через хттп, либо через конторллер
2. А недавно я написал один хттп эндпоинт, с 22 тестами из которых <50% работают через http.

В чём разница? В TA львиная доля эндпоинтов - примитивный КРУД - перегнать ДТО в сущность, сохранить сущность; вычитать ДТО из БД, вернуть - я это пишу спинным мозгом и там граничных случаев ноль целых хрен десятых.

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

В этом и разница.

—

Мысль №2
Что переход на более низкий уровень абстракции, что использование мока - снижают устойчивость тестов к рефакторингу и, как следствие, увеличивают стоимость разработки (читай: вашу нервотрёпку). Но, при этом снижают стоимость разработки самих тестов. И надо стараться искать оптимальное соотношение разных типов тестов, которое обеспечит минимальную стоимость разработки (читай: вашей нервотрёпки). Пока могу предложить это только в качестве лозунга - как конкретно искать этот баланс я не знаю.

—

Мысль №3
Возможно молодые подписчики ещё не сталкивались с http://wiki.c2.com/. Это самая первая вики в мире из 1995 года. От чувака, который придумал гексагональную архитектуру. И в которой в старые добрые времена тусила вся старая гвардия - начиная с самого Кокберна и продолжая анкл Бобом, Фаулером, Беком, Коплейном. Можно выделить вечерок и пошататься по ней впитывая мудрость древних.

—

Мысль №4
Чёт то ли я туплю, то ли у мужика не стыковка - он сначала пинает тесты с моками, за то что они мешают рефакторингу. А в конце доклада предлагает писать тесты на код интеграций с моками. Чтобы их потом не рефакторить?

—

Мысль №5
Мужик топит, за то, что код с вводом-выводом надо тестировать как-то по другому, потому что он медленный и хрупкий. И, видимо, раз я решил проблемы скорости и хрупкости такого кода, то мне можно и для него писать нормальные тесты. Можно же?

—

Мысль №6
У мужика в докладе ни строчки кода нет. А у меня есть ~150 "developer tests", которые "tests behaviour, not functions" и для которых процентов на 30 готово описание идей и техник как, такие тесты писать

#talks@ergonomic_code #ergo_testing@ergonomic_code #tdd@ergonomic_code #whynomocks@ergonomic_code

Привет!

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

Оказывается, предыдущий пост был юблиейным - 60-ый:)

У меня есть 27 "больших" постов (на самом деле тут не все посты большие, некоторые в формате микропоста, до тех пор пока я я не вытащил их на отдельную страницу)

Где ещё 26 микропостов (некоторые из которых на 40 минут чтения)

И у меня есть ещё пачка постов в Телеграфе:
1. Стратегия тестирования, которая сработает для большниства проектов
2. RPC over RabbitMQ
3. Чем ОО-подход отличается от ПП-подхода?
4. Kotlin и локальность рассуждений
5. Ленивые вычисления для реализации функциональной архитектуры
6. Тесты, которым можно доверять
7. Kotlin Result DSL

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

В общем, кажется, по кол-ву слов книгу я уже написал:) Может уже можно сделать сборник постов и опубликовать как книгу - как анкл Боб с Чистой архитектурой сделал?:)

#posts@ergonomic_code #ergo_approach@ergonomic_code

Привет!

Пара баек про JPA. Для молодых разработчиков, в первую очередь.

Мне тут недавно студент сдавал в качестве курсового проекта стартап с живым клиентом в проде. И между делом рассказал душещипательную историю в духе "У нас основное приложение на JPA, но в первый же день в проде оно нам покасячило данные, поэтому админку мы начали делать на jooq, чтобы лучше контролировать работу с БД".

А вчера говорил наоборот с пишущим код СТО c опытом работы с JPA лет 10 минимум и между делом я написал "в какой-то момент мне показалось, что я с JPA освоился и закончу активную разработку на этой недели".

На что получил ответ:

> Ахахаха
это классика
я после задач с JPA никогда не говорю теперь что с ним освоился/разобрался
я его б*ь не знаю, там вечные сюрпризы и темные пятна вылазят

В общем прежде чем брать в проект JPA советую сначала попробовать затолкать в голову собственно саму 662-страничную Jakarta Persistence API Specification :) Перед тем как ещё страниц ~100 рефернсной доки на Spring Data JPA читать. И я уж молчу про 228 страниц спеки на JDBC. Жаль, спека на SQL непубличная - говорят в свежих версиях там 1000 страниц. Кто-нибудь, остановите меня уже:)

#whynotjpa@ergonomic_code #jpa@ergonomic_code

Привет!

Опубликовал пост с последним кусочком описания сетапа фикстуры Trainer Advisor - сетап тестовых дублей.

В этом посте для полноты картины я добавил бонус-трек с описанием сетапа тестовых дублей для тестирования работы с внешними веб-сервисами, кроликом, кафкой и MQTT-брокером.

И под это дело добавил соответствующий бонус-трек в пост с описанием запуска инфраструктуры.

#trainer_advisor@ergonomic_code #ergo_testing@ergonomic_code #whynomocks@ergonomic_code

Привет!

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

Меня в первую очередь интересуют материалы такой же степени детализации/проработки как и 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