Обзор книги "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

Слайд 70 заслуживает отдельного поста. Варианты реализации OO/Functional Aggregates на примере Reference Applications by Chris Richardson:

Traditional OO mutable Domain Objects:
- https://github.com/cer/event-sourcing-examples/tree/master/java-spring

Functional Scala witn immutable Domain Objects:
- https://github.com/cer/event-sourcing-using-scala-typeclasses

Hybrid OO/Functional Scala with immutable Domain Objects:
- https://github.com/cer/event-sourcing-examples/tree/master/scala-spring

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

Листаю сейчас книжечку "Теоретический минимум по Computer Science", Фило Владстон.

В оригинале называется "Computer Science Distilled" by Wladston Ferreira Filho.

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

Содержит основы математики (логика, комбинаторика, вероятность), алгоритмы и структуры данных, основы Баз Данных (RDBMS, NoSQL), описание Парадигм Программирования и основы архитектуры железа.

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

#Algirithms #Basics #Math

P.S.: эту же информацию (Retry pattern) можно найти еще и в каталоге Cloud Design Patterns:
- https://docs.microsoft.com/en-us/azure/architecture/patterns/retry

#Microservices

Rob Pike, оказывается, кроме Golang, любит покодить интерпретатор функционального языка программирования... на Golang... Так что, теперь уже никто не скажет, что FP и Golang несовместимы 🙂))

📝 "This program was a joy to put together. Its purpose was fun and education, and in no way to create a modern or even realistic Lisp implementation."
- https://github.com/robpike/lisp

#FunctionalProgramming #Golang

📝 "Сначала художник рисует плохо и просто. Потом сложно и плохо. Потом сложно и хорошо. И только потом - просто и хорошо."
- И.Е. Репин

#SoftwareDesign #SoftwareArchitecture

> "Сначала художник рисует плохо и просто. Потом сложно и плохо. Потом сложно и хорошо. И только потом - просто и хорошо." - И.Е. Репин

Второе предложение этого выссказывания, "потом сложно и плохо", демонстрирует собою "Синдром второй системы". Мы его уже вспоминали.

#SoftwareDesign #SoftwareArchitecture