Привет!

Дочитал 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

Привет!

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

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

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

#books@ergonomic_code

Привет!

По совету подписчика начал читать Grokking Simplicity.

Пока прочитал 200 страниц из 600, но уже не могу удержать в себе восторг.

Это лучшая известная мне книга по функциональному стилю (или скорее data-oriented programming), с лучшим известным мне разбором двух основополагающих принципов проектирования:

1. разделение ввода-вывода и бизнес-логики
2. использование одного уровня абстракции в функции (анкл Бобовскя заметка на эту тему в чистом коде - даже близко не лежала с 1.5 главами об этом в книге).

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

#books@ergonomic_code #functional_architecture@ergonomic_code #fp@ergonomic_code #js@ergonomic_code

Привет!

Дочитал книгу. По традиции, тема разработки бэков поверх РСУБД практически не раскрыта (этому посвящено примерно 10 страниц про луковую архитектуру), но в остальном - чудесная книга, мой новый лидер среди книг по ФП.

И сейчас мой рекомендуемый трек по изучению разработки бэков в функциональном стиле выглядит так:
1. Grokking Simplicity
2. Принципы юнит тестирования
3. Domain Modeling Made Functional
4. Структура и интерпретация компьютерных программ
5. Functional Design: Principles, Patterns, and Practices
6. Structured Design

#books@ergonomic_code #functional_architecture@ergonomic_code #fp@ergonomic_code #js@ergonomic_code

Привет!

Прочитал Java to Kotlin: A Refactoring Guidebook - мне понравилась.
Её с тем же успехом можно было назвать "Рефакторинг императивного стиля в функциональный" и она хорошо дополняет Grokking Simplicity - на мой вкус менее фундаментальная, но более бакэндерская и со статической типизацией. Хотя, опять же, тема персистанса практически не раскрыта.

И в качестве инструкции по переходу на Котлин она тоже хороша.
Рекомендую, в общем.

Ещё пару находок оттуда:
1. Идея "волокон" (grains) языков программирования. "Вдоль" которых работать проще, чем поперёк - как с деревом. И ФП укладывается вдоль волокон Котлина, но идёт поперёк волокон Джавы. С одной стороны. С другой стороны, монады - не укладываются в волокна Котлина.

2. У Фаулера есть статья про баги вызванные алиасингом

3. Один из соавторов этой книги - также соавтор и Growing Object-Oriented Software Guided by Tests - книги, которую я долгое время считал идеологически вредной. В Java to Kotlin же он пишет, что в GOOS моки не предполагалось использовать в качестве стабов - поставщиков данных через ридонли методы. Возможно, мне стоит перечитать GOOS и поменять своё мнение о ней.

#books@ergonomic_code #functional_architecture@ergonomic_code #kotlin@ergonomic_code #java@ergonomic_code

Привет!

Прочитал Good to Great: Why Some Companies Make the Leap...And Others Don't

В книге описывают результаты исследования, где взяли 11 контор, стоимость акций которых 15 лет росла как рынок, а с определённого момента 15 лет подряд росла минимум в три раза быстрее рынка;
Для этих контор взяли 11 контор из тех же индустрий, которые 30 лет росли не лучше рынка;
И ещё взяли 6 контор, у которых был переломный момент, но 3ёх-кратный рост продлился менее 15 лет.

А потом попытались понять, чем 11 "good-to-great", контор похожи между собой и отличаются от остальных.

И вроде как поняли и описали что надо делать, чтобы забацать "great company".

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

Second, widen your definition of “right people” to focus more on the character attributes of the person and less on specialized knowledge. People can learn skills and acquire knowledge, but they cannot learn the essential character traits that make them right for your organization

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

#books@ergonomic_code #hr@ergonomic_code

Привет!

Список рекомендованных анкл Бобом книг
Я прочитал всё кроме Fundamental Algorithms и Analysis Patterns - есть ли в мире больший задрот, чем я?🤣🤓

#books@ergonomic_code

Привет!

У меня сегодня был прогон доклада с экспертом - Максом Моревым - и на обсуждении вспомнили почему в Красной книге (второй библии ДДД) примеры на Java:

First of all, and sad to say, I think there has been a general abandonment of good design and development practices in the Java community. These days it may be difficult to find a clean, explicit domain model in most Java-based projects.

Прежде всего, к сожалению, я думаю, что в Java-сообществе наблюдается общий отказ от хороших методов проектирования и разработки. В наши дни сложно найти чистую, явную модель предметной области в большинстве Java-проектов.

И наш с Максом опыт говорит о том же.

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

#books@ergonomic_code

Привет!

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

Я - задавался.

А сейчас начал читать матчасть по юзкейсам и узнал почему.

Оказывается, юзкейсы рекурсивны.

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

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

Ну и книгу я ещё прочитал только процентов на 50, но уже готов её порекомендовать.

#books@ergonomic_code #ergo_approach@ergonomic_code #ergo_arch@ergonomic_code

Что ещё почитать на тему тестирования
Принципы юнит тестирования - самая крутая книга на эту тему
TDD Revisited - Ian Cooper - NDC Porto 2023 - суть здорового тестирования за час пятнадцать
Пачка постов у меня про тестирование Trainer Advisor
Подборки постов у меня в канале - #tdd #nomocks

#ergo_testing@ergonomic_code #books@ergonomic_code #talks@ergonomic_code #posts@ergonomic_code

Привет!

И снова мне попалась дичь в переводе английской книги, которую я рекомендую к прочтению.

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

Не слушайте их - книгу можно и нужно читать и бакэндерам тоже.

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

#books@ergonomic_code

Привет!

Предистория.

Как вы знаете, я недавно ходил в гости к javaswag. Но, возможно, вы (как и я до этой записи) не знаете, что javaswag – это не только звук, но и нарезка видео, и небольшие тексты с комментариями к ссылкам.

У меня ссылок было аж 19 штук и Дима предложил сделать развёрнутые комментарии к ссылкам.
Но внезапно оказалось, что я не умею писать комментарии к ссылкам и вместо комментариев у меня как обычно вышел небольшой пост-очерк “Что такое ООП?”.
Но пост – уже не формат для javaswag, поэтому я его представляю вам у себя.

—-

История

В книге “What every programmer should know about object-oriented design” Пейдж-Джонс на первой же странице пишет:

Термин “объектно-ориентированный”, по сути своей, бессмысленен. “Объект” — это одно из самых общих слов в английском языке. Если вы посмотрите его значение в словаре, то увидите что-то вроде:

Объект — вещь, представленная или которую можно представить чувствам [человека].

Другими словами, объект - это практически всё что угодно.

Слово “ориентированный” также не особо помогает. Опредёленное как “направленный в сторону”, оно обычно используется для превращения термина “объекто-ориентированный” в прилагательное.
Таким образом, мы имеем:

Объектно-ориентированный — направленный в сторону практически чего угодно, о чём вы можете только подумать.

Не удивительно, что наша индустрия не смогла договориться об определении термина “объектно-ориентированный”.

Наверное, если провести опрос среди разработчиков, то самым популярным ответом будет “ООП – это наследование, полиморфизм и инкапсуляция”. И последний выпуск javaswag (см. ответ на моё непопулярное мнение), кстати, это подтверждает.

Однако Алан Кей, автор термина, в одном из своих докладов заявил: “На самом деле это я придумал термин “объектно-ориентированный” и я могу сказать вам, что я не имел С++ ввиду”.
А имел он ввиду: обмен сообщениями, сокрытие состояния и экстремально позднее связывание.

И, как следствие, Джо Армстронг, создатель Erlang считает: “Erlang, возможно, является единственным объектно-ориентированным языком, потому что три принципа объектно-ориентированного программирования заключаются в передаче сообщений, изоляции между объектами и полиморфизмом. [...] ООП — это не про объекты и классы, ООП — это про сообщения”.

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

А что такое ООП для вас?

#oop@ergonomic_code #terminology@ergonomic_code #archeology@ergonomic_code #books@ergonomic_code

Карта канала (Так же в Max)

Добро пожаловать на канал "Эргономичный код" — канал о разработке поддерживаемых кодовых баз в общем и моём подходе к этой задаче — Эргономичном подходе.

Что такое Эргономичный подход?
По большому счёту это небольшой набор принципов, взятых в основном из классической школы TDD, функциональной архитектуры и DDD, и большой набор рецептов — моделей, методик и шаблонов —, которые позволяют команде быстро создавать кодовые базы, соответствующие этим принципам и, как следствие, лёгкие в поддержке.
Подробности на сайте Эргономичного подхода

В Эргономичном подходе есть что-то уникальное?
Да. Идея представления системы как модели её эффектов в виде диаграммы эффектов и методика проектирования на базе этой модели.

"Слова дёшевы, покажи мне код!"
Trainer Advisor — некоммерческий, но реальный (~20K строк Котлин кода, 21 таблица, 2 настоящих пользователя, горки костылей, "компромиссных решений" и исторических наслоений) проект с открытым исходным кодом, разрабатываемый по Эргономичному подходу. В этот проект можно поконтрибьютить и на своём опыте прочувствовать работу с эргономичной кодовой базой.

Project Mariotte — минимальный демонстрационный пример кодовой базы, написанной по Эргономичному подходу, на примере операции бронирования номера в отеле

Есть что посмотреть или послушать?
Да, все мои публичные выступления собраны на одной странице

А почитать, кроме канала?
Да, в блоге

В блоге и канале есть подборки:
- Кейсы (в блоге, в канале #case@ergonomic_code)
- Примеры кода (в блоге)
- Эргономичный подход (в блоге, в канале #ergo_approach@ergonomic_code)
- Эргономичное тестирование (в блоге, в канале #ergo_testing@ergonomic_code)
- Функциональная архитектура (в блоге, в канале #functional_architecture@ergonomic_code)
- Эргономиный персистанс (в блоге, в канале #ergo_persistance@ergonomic_code)
- Что ещё почитать (в блоге, в канале #books@ergonomic_code, #posts@ergonomic_code, #papers@ergonomic_code)
- Что ещё посмотреть (в блоге, в канале #talks@ergonomic_code)

Какие ваши доказательства?
Исследование "Характеристики поддерживаемых кодовых баз backend-приложений"

А у меня вопрос!
Приходите в группу - там целому сообществу (более 100 крутых инженеров) можно задать любой вопрос по тематике канала - Эргономичный подход, классическая школа ТДД, ФА, ФП, в целом дизайн модели и системный дизайн

Как мне научить ИИ агента писать код по Эргономичному подходу?
Попробуйте раннюю версию моего фреймворка для ИИ-агентов.

Привет!

Прочитал The Problem with Software: Why Smart Engineers Write Bad Code - не однозначная книга.

С одной стороны - я не понимаю для кого она и зачем.

Автор явно разжевывает работу программистов для не программистов.
И рассматривает всё подряд - go to, слоёную архитектуру, объекты, аджайл, обработку ошибок и исключения.
При том разжевывает до такой степени, что объясняет как устроен стек, чтобы объяснить как переполнение локальных массивов в Си позволяет писать вредоносы.

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

С другой стороны книга написана хорошо и я с интересом её читал.

Советую её прочитать, если вы:
1. не закончили профильный вуз и не писали на Си и/или трансляторы - там как раз такие кишочки есть, что, на мой взгляд полезно разработчику. Хотя автор как раз считает иначе 😂
2. не программист, но вам очень любопытно как работа программиста устроена внутри - похоже вы один из двух людей в мире, являющихся целевой аудиторией этой книги 😂
3. любите историю - в книге многое говориться о становлении индустрии
4. любите древние книги и научные статьи - в тексте прям миллион ссылок на всё подряд

Мой текущий пост (который уже на стадии финальной полировки) очень хорошо иллюстрирует посыл этой книги - в нём есть такие строки:

И [анкл Боб] тут же говорит - это плохой код, который вносит новые зависимости в систему, и по мере развития системы и появления новых устройств в ней будет появляться всё больше зависимостей. И в итоге система станет жёсткой и хрупкой.

[...]

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

То бишь сначала анкл Боб бездоказательно заявляет, что в системах будут появляться новые устройства, а потом я так же бездоказательно заявляю, что не будут. Твоё слово против моего, встретимся в суде. Так и живут "инженеры" от современного ИТ...:)

#books@ergonomic_code

Привет!

Прочитал Shape Up.

Книга о том, как устроен процесс разработки в Basecamp - контора, которая наиболее известна созданием Ruby on Rails.

Книга в первую очередь для владельца конторы/продукта, но всё равно советую прочитать.
Во-первых, как и все книги от Бейзкампа читается легко за несколько дней.

Во-вторых, там есть несколько прикольных идей, про которые просто прикольно знать:)

Общий процесс у них такой:
1. есть два трэка - шейпинг и билдинг
2. на треке шейпинга они прорабатывают концепт проекта, на среднем уровне детализации - без детального проектирования, но так чтобы снять основные неизвестные и ограничить скоуп, чтобы создать ощущение, что проект впишется в цикл билдинга
3. шейпинг не ограничен по времени, потому что он как раз таки исследует "кроличьи норы" проекта
4. Цикл билдинга строго 6 недель. Если за 6 недель проект не выпустили в прод - по дефолту он отменяется совсем.
5. Между циклами билдинга есть 2 недели охлаждения, когда все выдыхают, подчищают хвосты, делают что сами считают важным и живут без дедлайна

Прикольные идеи:
Breadboarding - способ описания концепта проекта. Состоит из элементов - мест (places - страницы, модалки и т.д.), возможностей (affordance - кнопки, ссылки, динамические тексты) и связей (connection lines - в какое место ведёт возможность).

Я раньше на вход к проектированию бэка требовал макеты UI. Мне в ответ говорили "Ты дебил? Нафига тебе макеты для проектирования бэка?". На что я отвечал "А у вас требования такие, что по ним хрен разберёшь что конкретно надо сделать". В следующий раз надо будет попробовать такую штуку

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

Они себе в бейзкампе (я так понимаю что-то аля джиры) запили эти самые хил чарты и отслеживают статус проекта по ним.

Любопытный факт - у них на компанию с "миллионами пользователей и дюженой человек в производственной команде" только 1 QA-инженер, который занимается граничными случаями. Базовый уровень качества обеспечивает производственная команда, в том числе тестами.

#books@ergonomic_code

Привет!

Я всё ещё "гамак-дривеню" проекцию модели данных Эргономичной архитектуры и чтобы накинуть больше входных данных на обработку во сне своему большому мозолистому мозгу я начал читать Data Modeling Essentials. И там наткнулся на новую для себя концепцию в моделировании данных - предаваемость (transferability) отношения.

Отношение является передаваемым, если допустимо менять сущность на одной из сторон.
Например, отношение "Заказ такси" -> "Водитель" является передаваемым. К сожалению.
А вот "Заказ такси" -> "Заказчик" - нет.

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

Ну и т.к., имхо, ДДД Агрегаты и сущности+слабые сущности - это одни и те же яйца только в профиль, то можно брать на вооружение эту эвристику при проектировании агрегатов - включать в агрегат только то, что невозможно передать другому агрегату. Не то чтобы супер прорыв, но эврстик много не бывает, на мой взгляд.
NB: и на всякий случай - это необходимое, но недостаточное условие - ни Заказ, ни Заказчик не являются частью агрегата друг друга.

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

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

#ergo_arch@ergonomic_code #ergo_data_model@ergonomic_code #ergo_persistance@ergonomic_code #books@ergonomic_code #ddd@ergonomic_code

Привет!

What else changes for different reasons? The use cases themselves! The use case for adding an order to an order entry system almost certainly will change at a different rate, and for different reasons, than the use case that deletes an order from the system. Use cases are a very natural way to divide the system.

At the same time, use cases are narrow vertical slices that cut through the horizontal layers of the system. Each use case uses some UI, some application-specific business rules, some application-independent business rules, and some database functionality. Thus, as we are dividing the system into horizontal layers, we are also dividing the system into thin vertical use cases that cut through those layers.

To achieve this decoupling, we separate the UI of the add-order use case from the UI of the delete-order use case. We do the same with the business rules, and with the database. We keep the use cases separate down the vertical height of the system.

—

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

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

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

— Роберт Мартин, Clean Architecture, глава 16. Independence, раздел Decoupling Use Cases

Значит ли это, что Чистая архитектура ближе к вертикальной, чем к слоёной? И в коде по чистой архитектуре должна быть пачка интерфейсов в духе RegisterUserGateway, DeleteUserGateway и т.п. вместо UsersGateway.
Как знать - анкл Боб почему-то решил не показывать реальный пример реализации чистой архитектуры.
Может в этом секрет популярности - написать в целом убедительный, но внутренне противоречивый текст, в котором каждый найдёт то, что ему нравится?

Не спрашивайте как меня опять занесло перечитывать эту книгу.

#clean_arch@ergonomic_code #books@ergonomic_code

Привет!

Вычитал тут в синей книги интересное про сущности.

Modeling ENTITIES
ENTITIES are defined by their identities. Attributes are attached and change. Therefore, strip the ENTITY object’s definition down to the most intrinsic characteristics, particularly those that identify it, or are commonly used to find or match it. Separate other characteristics into other objects associated with the core ENTITY.

Figure 5. 1
The name does not define a person’s identity, but it is often used as part of the means of determining it.

Many would dispute moving phone and address into Customer. It depends on how Customers are typically matched or distinguished. If a Customer has many contact phone numbers for different purposes, then the phone number is not associated with identity and should stay with the Sales Contact. The customerID is the one and only identifier of the ENTITY, but the phone number, name and address would often be used to find or match a Customer.

—

Моделирование СУЩНОСТЕЙ (ENTITIES)

СУЩНОСТИ определяются своей идентичностью. Их атрибуты прикреплены к ним и могут изменяться. Поэтому необходимо свести определение объекта-СУЩНОСТИ к его наиболее внутренним, сущностным характеристикам — особенно тем, которые идентифицируют его или часто используются для поиска или сопоставления. Остальные характеристики следует вынести в отдельные объекты, связанные с ядром СУЩНОСТИ.

Иллюстрация 5.1
Имя само по себе не определяет идентичность человека, но часто используется как часть механизма её определения. Многие поспорили бы насчёт включения телефона и адреса в Customer. Это зависит от того, как обычно клиентов сопоставляют или различают. Если у клиента есть много телефонных номеров для разных целей, то телефон не связан с идентичностью и должен оставаться в Sales Contact. customerID — единственный истинный идентификатор СУЩНОСТИ, но телефон, имя и адрес часто используются для поиска или сопоставления клиента.

Я смотрю в этот абзац и вижу там свои сущности-аспекты (и пример).
Меш тем, сущности-аспекты - это основная причина, почему я завожу собственную номенклатуру блоков, вместо ддд-шных сущностей и объектов-значений.
Сижу теперь и думаю, то ли дальше со своей сидеть (прописав в примечании совместимость с ДДД), то ли перейти на ДДД-шную, дополнив её типами сущностей (мне ещё справочники нужны) и сделав отсылку на это место.

#ddd@ergonomic_code #books@ergonomic_code

Привет!

У меня в Эргономичной архитектуре есть ограничение на количество атрибутов сущностей и зависимостей операций (сервисов) с рекомендуемым значением "до 7 +/- 2".

И вот я в очередной раз наткнулся, на то, что это не я один такой умный сумасшедший, но есть и общепризнанные авторитеты, разделяющие ту же точку зрения:)

Я тут в рамках разработки Ergo AI Agent Framework пошёл снова ботанить понятия cohesion и coupling, и, в частности, пошёл читать Code Complete (aka Совершенный код).

И там на странице 143 английским по белому написано:

Be critical of classes that contain more than about seven data members
The number “7±2” has been found to be a number of discrete items a person can remember while performing other tasks (Miller 1956). If a class contains more than about seven data members, consider whether the class should be decomposed into multiple smaller classes (Riel 1996). You might err more toward the high end of 7±2 if the data members are primitive data types like integers and strings, more toward the lower end of 7±2 if the data members are complex objects.

—

Критически относитесь к классам, содержащим более чем примерно семь полей данных.
Число «7±2» было выявлено как количество отдельных элементов, которое человек способен удерживать в памяти, выполняя при этом другие задачи (Miller, 1956). Если класс содержит более примерно семи полей данных, сто́ит задуматься о том, не следует ли разложить его на несколько более мелких классов (Riel, 1996).

Можно смещаться ближе к верхней границе диапазона 7±2, если поля представлены примитивными типами данных, такими как целые числа и строки; и ближе к нижней границе, если поля являются сложными объектами.

Возможно, вы, глядя на свою MyCoreEntity с 100+ полей и MyCoreEntityService с 80+ зависимостей, думаете, что мы с Макконнеллом теоретики, которые реального кода в глаза не видели.
Но это не так:)

Может быть, и не до 7 полей, но существенно упросить MyCoreEntity можно с помощью:
1. активного выделения Value Object-ов — например, завести класс PersonName(first, middle, last) и заменить три поля на одно;
2. активного выделения аспектов сущности в отдельные сущности — например, убрать из коренной сущности пользователя поле с его подписками, на веб-пуши.

А справиться с MyCoreEntityService поможет:
1. переход от сервисов к классам-операциям (ака юз-кейсам, интеракторам) — выделение каждого метода класса сервиса в отдельный класс с одним публичным методом. С непривычки это кажется дичью — по себе знаю, мне самому так казалось 2.5 года назад — но к этому быстро привыкаешь и назад уже не хочется;
2. повышение уровня абстракции ресурсов/гейтвеев/портов — например, если у вас агрегат включает в себя блоб (картинку), то можно заменить зависимость от UsersRepo и FilesStorage на сложный/составной ресурс/порт/гейтвей, которые внутри себя держит UsersDao для работы с РСУБД и FilesStorage для работы с хранилищем блобов.

#ergo_arch@ergonomic_code #books@ergonomic_code

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

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

#ergo_approach@ergonomic_code #books@ergonomic_code #project_e@ergonomic_code