Еще одна превосходная статья на тему Side-effect of CQRS-query (thanks to @vkhorikov ):
"Applications and their side effects" by Mark Seemann
https://blog.ploeh.dk/2015/09/23/applications-and-their-side-effects/

#DDD #Microservices #SoftwareDesign #SoftwareArchitecture #FunctionalProgramming

С поддержкой Generics в Golang открываются новые возможности в использовании приемов функционального программирования.

См. главу "Monadic Error Handling":
https://awalterschulze.github.io/blog/post/monads-for-goprogrammers/

Это вынуждает по новому взглянуть на широко известный среди функциональщиков Railway Oriented Programming:
- https://fsharpforfunandprofit.com/rop/
- https://fsharpforfunandprofit.com/posts/against-railway-oriented-programming/

Перевод на русский статьи "Railway Oriented Programming":
- https://habr.com/ru/post/339606/

Еще одна ссылка, на эту тему:
- https://medium.com/@naveenkumarmuguda/railway-oriented-programming-a-powerful-functional-programming-pattern-ab454e467f31

А здесь, на слайдах, показана трансформация UseCase of Robert Martin в Railway Oriented Programming:
- https://github.com/swlaschin/RailwayOrientedProgramming/blob/master/Railway_Oriented_Programming_Slideshare.pdf
- https://github.com/swlaschin/RailwayOrientedProgramming/blob/master/Railway_Oriented_Programming.pptx
- https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html#use-cases

Кстати, это является и ответом на вопрос, есть ли жизнь без синхронных Domain Events:

📝 "In an object-oriented design, it is common to have domain events raised internally within a bounded context. In that approach, a workflow object raises an OrderPlaced event, and then a handler listens for that and sends the order acknowledgement, and another handler generates a BillableOrderPlaced event, and so on.
<...>
In a functional design, we prefer not to use this approach, because it creates hidden dependencies. Instead, if we need a “listener” for an event, we just append it to the end of workflow...
<...>
This approach is more explicit – there are no global event managers with mutable state – and therefore it is easier to understand and maintain."
- "Domain Modeling Made Functional. Tackle Software Complexity with Domain-Driven Design and F#" by Scott Wlaschin
https://fsharpforfunandprofit.com/books/

Кстати, на github.com по этой теме в топе ребята из @drypython :
- https://github.com/topics/railway-oriented-programming

Одна из библиотек, облегчающих использование Railway Oriented Programming в Python: https://github.com/proofit404/stories

#FunctionalProgramming #DDD #Golang

Кстати, агрегаты вот этого DDD/Golang reference application https://github.com/AntonStoeckl/go-iddd выполнены в функциональной парадигме. Об этом автор пишет в сопроводительных статьях к приложению.

📝 "My Aggregate used to be implemented in OOP style with inline state in the past. My little project is event-sourced and I decided a while ago that I want to implement a functional core. Event-Sourcing is quite functional by nature, so I decided that my Aggregate will only consist of functions! My first functional version did not even have a state object. It simply projected all necessary properties into local variables. Not long ago I introduced a currentState object — which is unexposed — so only visible inside the Domain subpackage customer in which my Aggregate lives."
- "Implementing Domain-Driven Design and Hexagonal Architecture with Go (2). Part 2 — How I implement tactical DDD patterns — the Domain layer" by Anton Stöckl
https://medium.com/@TonyBologni/implementing-domain-driven-design-and-hexagonal-architecture-with-go-2-efd432505554

#DDD #Golang #FunctionalProgramming

#Golang #FunctionalProgramming

По поводу https://news.1rj.ru/str/emacsway_log/377 и функциональщины

Надо понимать что у golang2 пока непонятно как будут обстоять дела с контролируемым развёртыванием хвостовой рекурсии, и будут ли для этого дополнительные примитивы (@tailrec аннотация в случае с JVM языками).

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

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

IO нужен для ROP'a и весь код обёрнутый внутри автомагически будет работать по ROP'у без дополнительных плясок.

Потому Eval/IO довольно сложно реализованы что в Cats / Scalaz что в Arrow.kt.
Для Arrow пришлось отдельный плагин к компилятору писать (https://github.com/arrow-kt/arrow-meta), ну и для скалы тоже есть для better-monadic-for плагин (https://github.com/oleg-py/better-monadic-for).

Как это будет реализовано в голанге - непонятно, но про модульность плагинов к компилятору точно можно не мечтать.

Для тех, кто работает с Golang, - смотрел как-то я эту книгу: "Hands-On Software Architecture with Golang. Design and architect highly scalable and robust applications using Go." by Jyotiswarup Raiturkar
Copyright © 2018 Packt Publishing

Она прекрасна. Удивительное сочетание полноты информации и её краткости. Это скорее конспект, а не книга. Курс молодого бойца. Никакой воды - только все самое нужное. Вряд-ли есть другой способ получить такой колоссальный объем знаний из одной книги. Она, поистине, шедевральна в этом смысле.

Дано практически все, что нужно знать разработчику, на примере Golang. Виды согласованностей, в т.ч. Causal Consistency, Векторные Часы, CAP-теорема, способы достижения консенсуса, в т.ч. RAFT, Paxos, 2PC, основы ООП, композиция vs наследование (кстати, на примере зверушек - известный пример), Design Patterns, основы работы с БД, индексы, формы нормализации, виды транзакций (ACID, BACE), матрица уровней изоляции транзакций, брокеры сообщений, принципы масштабирования и многое другое.

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

Раз уж речь зашла про Packt Publishing, то еще было бы уместно упомянуть "Learning Functional Programming in Go. Change the way you approach your applications using functional programming in Go." by Lex Sheehan
Copyright © 2017 Packt Publishing

И "Hands-On High Performance with Go. Boost and optimize the performance of your Golang applications at scale with resilience" by Bob Strecansky
Copyright © 2020 Packt Publishing

#Golang #SoftwareDesign #SoftwareArchitecture #FunctionalProgramming

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

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

- https://postgrespro.ru/education/books

1. "Postgres: первое знакомство"
- https://postgrespro.ru/education/books/introbook

2. "PostgreSQL. Основы языка SQL"
- https://postgrespro.ru/education/books/sqlprimer

3. "Основы технологий баз данных"
- https://postgrespro.ru/education/books/dbtech

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

Так же доступны учебные материалы курсов: слайды, видео, руководства. Скачать можно все материалы каждого курса одним архивом:
- https://postgrespro.ru/education/courses

Видеозаписи курсов:
- https://postgrespro.ru/education/where

Превосходная подборка статей с фундаментальной информацией простым языком о внутреннем устройстве PostgreSQL, от разработчиков PostgresPro:
- https://m.habr.com/ru/company/postgrespro/blog/442804/
- https://m.habr.com/ru/company/postgrespro/blog/458186/
- https://m.habr.com/ru/company/postgrespro/blog/459250/
- https://m.habr.com/ru/company/postgrespro/blog/460423/
- https://m.habr.com/ru/company/postgrespro/blog/461523/

Ну и пара превосходных книг от разработчика PostgreSQL, но уже не в свободном доступе:

- "Mastering PostgreSQL In Application Development" by Dimitri Fontaine

- "The Art of PostgreSQL" 2nd edition by Dimitri Fontaine - is the new noscript of "Mastering PostgreSQL in Application Development"

#Database #PostgreSQL

Хорошее руководство для тех, кому предстоит изменять структуру базы данных PostgreSQL с большими массивами данных без downtime:

"PostgreSQL at Scale: Database Schema Changes Without Downtime" by James Coleman
https://medium.com/braintree-product-technology/postgresql-at-scale-database-schema-changes-without-downtime-20d3749ed680

#Database #PostgreSQL

Обзор книги "Fundamentals of Software Architecture: An Engineering Approach" 1st edition by Mark Richards, Neal Ford
https://apolomodov.medium.com/%D0%BE%D0%B1%D0%B7%D0%BE%D1%80-fundamentals-of-software-architecture-1754c0e78d48

От Alexander Polomodov - Director of digital ecosystem development department at Tinkoff.

#SoftwareArchitecture #Career

Обзор книги "What Is Domain-Driven Design?" by Vladik Khononov ( @vladik_kh )

Книга:
https://www.oreilly.com/library/view/what-is-domain-driven/9781492057802/

Обзор:
https://apolomodov.medium.com/%D0%BE%D0%B1%D0%B7%D0%BE%D1%80-%D0%BA%D0%BD%D0%B8%D0%B3%D0%B8-what-is-domain-driven-design-7128373196e8

От Alexander Polomodov - Director of digital ecosystem development department at Tinkoff.

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

#SoftwareArchitecture #SoftwareDesign #DDD #Microservices

Коллеги обратили мое внимание на статью "Радикальный перфекционизм в коде"
https://habr.com/ru/post/543490

У меня появилось несколько мыслей, которыми можно поделиться. Будет несколько постов.

Стоит отметить, что хотя автор старался отделить моментами Code Style от Code Smell (и подчеркивал это в комментариях), но статья затрагивает оба аспекта, из этого и будем исходить.

#SoftwareDesign

> переименовывающим getJson в getJSON

Очень тонкий вопрос. Правило getJSON не универсально, и не будет работать для snake_case (get_j_s_o_n). Т.е. общее количество правил растет для каждого частного случая. А базовый критерий хороших правил - минимализм. Хороший пример - объем документация к языку Оберон стал в 3 раза меньше, чем к языку Паскаль. При этом автор обоих языков один и тот же. Т.е. эволюционирование заключается в поиске форм упрощения. Как не вспомнить тут не вспомнить Дейкстру:

📝 "Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better."
- Edsger W. Dijkstra, 1984 On the nature of Computing Science (EWD896)

Запись вида get_j_s_o_n() затрудняет восприятие. Если стремиться минимизировать подмножество правил, тогда getJson() или get_json(). Одно и то же правило и для CamelCase и для snake_case.

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

#SoftwareDesign

А вообще, по поводу Code Style - тут палка о двух концах. С одной стороны, действительно, это не Code Smell, и на экономику разработки не сильно влияет. С другой стороны, как говорил мой зам.декана, если студент что-то сделал на тройку, то проблема не в том, что он так сделал, а в том, что у него есть привычка делать на тройку. Если он сделал на тройку малоответственную задачу, то поручи ему ответственную, и он сделает её точно так же.

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

#SoftwareDesign

> "Увидел пару switch case — сразу городи иерархию классов. Так ведь в книжке написано."

Здесь есть два важных момента, но рассмотрим мы только технический.

По всей видимости, речь идет о книге "Refactoring: Improving the Design of Existing Code" by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts

Эта книга хорошо раскрывает основы экономики разработки. На эту тему у меня была серия постов, начиная отсюда https://news.1rj.ru/str/emacsway_log/119 (можно еще поискать в канале по термину "YAGNI"). Эта книга, как раз, учит не экономически необоснованному перфекционизму, а наоборот, достижению наилучшей экономики разработки в балансе краткосрочных и долгосрочных интересов. И Code Smell "Switch Statement" прямо гласит о том, что он требует исправления только тогда, когда он приводит к разлету дроби. В другом месте книги говорится о правиле трех ударов, и два дубликата - еще не повод для рефакторинга, но уже на грани.

#SoftwareDesign

Ключевой критерий качества кода - это темпы разработки, т.е. стоимость изменения кода. Это необходимое условие для Agile-разработки. На эту тему был пост: https://news.1rj.ru/str/emacsway_log/151

Все правила должны быть нацелены на достижение этой цели. Если возникают разногласия, то я рекомендовал бы обращаться к общепризнанным каталогам Code Smells. Доказано практикой - конфликты исчезают.

А про Code Style - очень хорошо у Steve McConnell в "Code Complete". Он дает понимание того, что и как оформлять в коде, что исключает догматичное следование правилам. Кстати, с некоторыми правилами, общепризнанными в Golang, я не согласен, и считаю, что слепо преклоняться не стоит. Например, я считаю, что функции-конструкторы обязаны содержать глагол, а не прилагательное.

#SoftwareDesign

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

Вот это основная суть статьи. Это - самая главная проблема в разработке. И это касается не только правил, но и кода:

📝 "A six-month study conducted by IBM found that maintenance programmers “most often said that understanding the original programmer’s intent was the most difficult problem”" - Fjelstad and Hamlen

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

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

Но даже когда намерения автора понятны, должна быть возможность выполнить задачу в существующем коде, т.е. изменить код автора. Если код представлен лапшой, то придется изменять много кода, изменения будут лавинообразными. По этому поводу хорошо рассуждал Kent Beck: https://news.1rj.ru/str/emacsway_log/188

Чтобы код не был лапшой, нужно изолировать изменения. Поэтому, второе самое важное правило Software Design - это принцип "Low Coupling & High Cohesion" ( http://wiki.c2.com/?CouplingAndCohesion ), сформированный еще в 1974 году. Главное правило рыбака - не дать запутаться леске. Главное правило программиста - предотвратить Уроборос.

И, наконец, третье важное правило - чтобы что-то изменить, нужно понять, как оно работает сейчас. А для этого нужно иметь возможность рассмотреть фрагмент программы изолированно, чтобы сложность рассматриваемого фрагмента не превысила ограниченные возможности краткосрочной памяти человека.
https://ru.m.wikipedia.org/wiki/%D0%9C%D0%B0%D0%B3%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B5_%D1%87%D0%B8%D1%81%D0%BB%D0%BE_%D1%81%D0%B5%D0%BC%D1%8C_%D0%BF%D0%BB%D1%8E%D1%81-%D0%BC%D0%B8%D0%BD%D1%83%D1%81_%D0%B4%D0%B2%D0%B0

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

> От навязанных необоснованных ограничений мы получаем выгорание.

Тут он говорит то же самое. Объектом критики выступают не сами правила, а отсутствие понимания причин этих правил. Именно поэтому, одной из самых ключевых практик Agile-разработки является Collaborative Development (т.е. методики распространения знаний). Понимание - единственная причина, позволяющая гарантировать соблюдение правил.

Таким образом, цель правил должна сводиться не к "читабельности", а к сохранению характера роста стоимости изменения кода близкого к горизонтальной асимптоте, чтобы не позволить ему свалиться в экспоненту. И на достижение этой цели должно быть направлено Code Review.

#SoftwareDesign

> Раньше мне казалось, что начальство перегибает палку ради дисциплины в вакууме, и меня от этого бомбило.

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

Часто конфликтность подогревается дисфазностью "Спирали Обучения" оппонентов, об этом было в постах:
- https://news.1rj.ru/str/emacsway_log/48
- https://news.1rj.ru/str/emacsway_log/113

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

Да и изменяется качество самих правил - "орел мух не ловит", а "лев падалью не питается". Мелочь отбрасывается или полностью автоматизируется, а по-настоящему важные правила - подчеркиваются и усиливаются.

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

#SoftwareDesign

Конспект известной статьи V.Vernon о моделировании агрегатов:
https://m.habr.com/ru/post/543424/

(Источник)

#DDD

Статья С.Теплякова о Switch Statement:
"Что не так с оператором switch?"
- http://sergeyteplyakov.blogspot.com/2016/08/whats-wrong-with-switch-operator.html

#SoftwareDesign

К вопросу о паттернах проектирования:
"Шаблоны проектирования. История успеха"
- http://sergeyteplyakov.blogspot.com/2010/01/blog-post.html

#SoftwareDesign

Тут как раз Chris Richardson написал blog-post, затрагивающий проблему atomicity and resiliency of event publishing:
"Events on the outside, on the inside and at the core" by Chris Richardson
http://chrisrichardson.net/post/microservices/2021/02/21/events-are-the-core.html

Слайды заслуживают внимания. Также они демонстрируют сегодняшние тренды в микросервисной архитектуре, и какую роль в этом играет DDD.

#DistributedSystems #EIP #EDA #DDD #Microservices #Golang #SoftwareArchitecture #SoftwareDesign