Привет!

Пересмотрел старый доклад моего любимого Рича Хикки.
Он там прямым текстом говорит, что доклад не про то, чтобы попинать ООП, но получается у него очень хорошо. При том на фундаментальном уровне.

Но самая крутая на мой взгляд штука - это Эпохальная Модель Времени, кратко описная здесь.

Очень рекомендую к вдумчивому просмотру

#talks@ergonomic_code #fp@ergonomic_code #clojure@ergonomic_code #immutable_domain_model@ergonomic_code

Привет!

Объявляю идейный кризис эргономичного подхода успешно преодолённым:) В частности с агрегатами и Spring Data JDBC всё так, это у меня была ошибка в ДНК.

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

Эргономичный подход - это подход к разработке ПО с минимальной связанностью (coupling) и как следствие с максимальной связностью (cohesion).
Программы с минимальной связностью дёшевы и легки в поддержке благодаря простоте понимания и лёгкости модификации.

Эргономичный подход стоит на трёх столпах:
1) Декларативный стиль программирования
* Это позволяет минимизировать связанность по общей области и управлению (common & control coupling)
2) Декомпозиция системы на модули с высокой связностью и низкой связанностью
* Это и делает систему простой для понимания и лёгкой в поддержке
3) Детройтская школа тестирования
* Это минимизирует связанность между тестами и деталями реализации

От мейнстримового подхода Эргономичный подход отличается следующим:
1) Использование модели неизменяемых связанных данных (Immutable Relation Data) на базе агрегатов DDD и эпохальной модели времени для моделирования информации системы (а не модели графа изменяемых объектов)
2) Стремление максимум кода вынести в функции без побочных эффектов (а не бессистемное разбрасывание побочных эффектов по всему коду)
3) Применение архитектурного стиля функциональное ядро/императивная оболочка (а не классической слоёной архитектуры)
4) Разделение слоя бизнес-логики на подслой приложения (оркестрация выполнения операции системы) и подслой предметной области (сложные бизнес-правила, задействующие несколько агрегатов) (а не единый слой сервисов)
5) Верхнеуровневое разбиение на модули системы (а не слои)
6) Минимизация зависимостей между модулями системы (а не произвольное добавление новых зависимостей в систему)
7) Тестирование системы на соответствие требованиям (а не покрытие тестами классов и методов)
8) Мокирование только дорогих или нестабильных внешних систем (а не всех классов, помимо тестируемого)
9) Для достижения пп 1-3 и 6 - использование Spring Data JDBC (а не Spring Data JPA)
10) Для достижения п. 6 - ручное управление зависимостями (а не Spring Component Scan)

P. S>
это ещё и линко пост был:)
Immutable Relational Data - коротенько (30 минут) о там как жить с неизменяемой моделью данных (в данном конкретном случае на примере веб-фронта на Elm-е)
эпохальная модель времени - как моделировать изменения в неизменяемой модели данных

P.P.S>
Промахунлся:(

#immutable_domain_model@ergonomic_code #ergo_approach@ergonomic_code

Привет!

Наконец-то опубликовал долгожданный (надеюсь:)) пост про агрегаты:)
И это не первоапрельская шутка:)

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

#posts@ergonomic_code #ddd@ergonomic_code #immutable_domain_model@ergonomic_code

Привет!

Пост про ОО-декомпозицию начинает обретать вменяемый вид - надеюсь в течении пары недель закончить:)

А тем временем, буду радовать вас линкопостами:)
Вот очень крутой конспект/лекция (?) из MIT-а про изменяемость/неизменяемость, с хорошими примерами рисков, которые несёт изменяемость. Если вы по дефолту используете изменяемое состояние - рекомендую прочитать, может быть передумаете:)

А если вы используете неизменяемое состояние и Котлин - то вот небольшая библиотека для упрощения жизни. Сам ещё не пробовал её

#posts@ergonomic_code #whyfp@ergonomic_code #immutable_domain_model@ergonomic_code

Привет!

В продолжение темы неизменяемых данных: Почему Java делает так много штук неизменяемым?
ТЛ/ДР - потому что неизменяемые штуки потоко-безопасны и благодаря постоянным улучшениям JVM создание нового объекта зачастую может быть быстрее мутации старого

#posts@ergonomic_code #immutable_domain_model@ergonomic_code #java@ergonomic_code

Привет!

"Хочешь насмешить бога - расскажи ему о своих планах" (с) Народ.

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

А ещё то, что на этой же недели у меня заболеет ребёнок 🤯

Поэтому план уже точно поедет как минимум на неделю.

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

#immutable_domain_model@ergonomic_code #ergo_approach@ergonomic_code #ergo_persistance@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

Привет!

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

В ОО-модели сущность (якобы) инкапуслирована в объектах, а репозы/дао/объекты таблиц - это просто индексные указатели, которые используются для поиска объектов. И чтобы поменять объект, вам надо его найти, позвать пару сеттеров и (теоретически) готово.

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

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

ОО же модель и ОРМы пытаются сделать вид, как будто сущность инкапуслирована в объектах. И чтобы это попытаться сделать требуются титанические усилия в виде персистанс контекста, модели состояний сущностей, проксей и дёрти чекинга. И всё равно это всё течёт - у вас вполне может появится в процессе два разных объекта, якобы инкапсулирующих одну сущность. И если сеттер у вас не взорвался с исключением, это ещё не значит, что сущность на самом деле обновилась.

Надеюсь, в течении пары месяцев напишу развёрнутый пост на эту тему. После поста "Почему ФП" - там у меня тоже появилась идея:)

#immutable_domain_model@ergonomic_code