Среди особенностей моего подхода к разработке у моих заказчиков, коллег и студентов наибольшее сопротивление вызывает использование Spring Data JDBC, а не [Spring Data] JPA (де-факто стандарта работы с БД на платформе Java).

Изначально я собирался писать пост "Почему не JPA", но немного подумав понял, что ответ умещается в одно предложение: потому что JPA по своей природе (persistence context и dirty checking) не поддерживает неизменяемую модель данных - неотъемлемую часть функционального стиля программирования, который, в свою очередь, является неотъемлемой частью моего подхода к разработке. И это объективный факт.

Почему для себя я выбрал ФП, а не "нормальное" императивное программирование? На этот вопрос также можно ответить одним предложением: потому что функциональный стиль помогает мне снижать стоимость разработки для бизнеса и делать руководителей проектов счастливыми.

Уверен, многие не согласятся с истинностью утверждения "применение функционального стиля ведёт к снижению стоимости разработки". Поэтому я пока буду называть его Гипотезой и приведу факты, доказывающие её истинность.

В своём прошлом посте я рассказал теорию своего подхода к декомпозиции систем на модули. Теперь пришло время проверить её на практике.

Кэмп - реальный проект, который стоил семизначную сумму для заказчика, выполнялся командой из 12 человек (включая двух бакэндеров) и сейчас запущен в промышленную эксплуатацию. Суммарно на выполнение проекта было затрачено 5500 человеко/часов, из которых 950 - на бакенд.

Чего от разработки ПО хотят разработчики, продакты и владельцы бизнеса?

Одного и того же - побольше дофаминчика (гормон счастья), поменьше кортизольчика (гормон стресса). Притом источники и дофамина, и кортизола у них одни и те же. Дофамин вырабатывается, когда фичи выпускаются в срок и без багов, а кортизол - когда сроки срываются и вылазят баги и регрессии. Бизнесу будет ближе финансовая версия — срыв сроков и баги очевидным образом приводят к увлечению стоимости разработки. Что приводит к выбросу кортизола уже у владельцев.

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

Сейчас наиболее распространены два основных подхода к декомпозиции систем: пакетирование по слоям и техническим аспектам (далее просто "по слоям" для краткости) и пакетирование на основе предметной области (представленное группой вариантов: пакетирование по фичам, пакетирование по компонентам, ограниченные контексты и пакетирование по агрегатам из предметно-ориентированного дизайна (DDD))

Однако ни один из этих подходов мне не подошёл в полной мере и я изобрёл…​ объектно-ориентированный подход к декомпозиции систем. Точнее, я изобрёл простую методику выполнения декомпозиции, а потом понял, что на выходе она даёт штуки обладающие свойствами объекта.

Но обо всём по порядку - сначала я рассмотрю критерии оценки подходов, распространённые подходы и почему они мне не подошли. А закончу пост представлением методики выполнения объектно-ориентированной декомпозиции.

Почти 30 лет назад в классической книге по шаблонам проектирования Design Patterns: Elements of Reusable Object-Oriented Software, авторы сформулировали один из самых известных, но недопонятых принципов в истории программирования:

Program to an interface, not an implementation.

— Erich Gamma et. al, Design Patterns: Elements of Reusable Object-Oriented Software

Зачем "программировать в интерфейсы"?

Ведущие разработчики (ака техлиды, тимлиды, архитекторы) встречаются с целым рядом нетривиальных вопросов:

1) Как оценить трудоёмкость задачи?

2) Как обеспечить низкую сцепленность системы?

3) В каком порядке реализовывать части системы и как эффективно распараллелить работу?

4) И ключевой вопрос - а что вообще надо сделать-то?

Я для поиска ответов на эти вопросы использую диаграмму эффектов. Чтобы научить этому и свою команду, в этом посте я подробно описал процесс создания диаграммы эффектов своего последнего коммерческого проекта.

Идентичность информационной системы определяется тем, как она взаимодействует с внешним миром. Что, где и когда она сохраняет и запрашивает; что, куда и когда отправляет. Это я называю наблюдаемым поведением.

Можно переписать приложение с Java на Haskell, сменить слоёную архитектуру на шестиугольную, реляционную базу данных заменить документной, а пользовательский интерфейс перевести с серверной генерации HTML на React Native - если наблюдаемое поведение системы останется неизменным, то это будет просто очередная версия всё той же системы. Если же кардинально изменить её взаимодействие с внешним миром, то это будет уже другая система.

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

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

... или как писать программы, которые приносят больше положительных эмоций.

Работу над Эргономичным подходом я начал весной 2020 года. Причиной тому стал возврат к работе над стандартными для экосистемы Spring-а проектами после четырёхлетнего перерыва.

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

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

Я считаю, что именно агрегаты из Domain-Driven Design лежат в основе поддерживаемых информационных систем. Однако эта концепция малоизвестна за пределами DDD-сообщества и довольно сложна для понимания, поэтому я решил написать очередной пост посвящённый агрегатам. В основном для чтобы структурировать собственное понимание агрегатов и создать "методичку" для своих команд, но и широкой общественности, я надеюсь, этот пост тоже может быть полезен.

Принцип единственности отвественности? Что именно вы имеете ввиду?

JPA безусловно самая распространённая технология работы с базами данных на платформе Java. Но она же и наименее пригодна для разработки быстрых и поддерживаемых систем. В этой статье я расскажу почему JPA лучше не использовать в продакшене и что можно использовать вместо неё.

Если вы недавно начали: 1) пользоваться Sublime Text и/или 2) пользоваться плагином Vintage и/или 3) редактировать много текста на русском (или наоборот английском) языке с использованием ST3+Vintage, то скорее всего уже почувствовали какая боль связана с командами назначенными на символы пунктуации — "$", ";", ".", ",", """ и т.п. В небольшой заметке под катом я хочу предложить вам пару костылей, которые помогают эту боль в значительной степени облегчить.

• http://www.youtube.com/watch?v=dqHmp_kMz-U — Дуэль
• http://www.youtube.com/watch?v=eqlPbtO3rQY — Дуэль
• http://www.youtube.com/watch?v=zx7xFJiBGZQ — Схватка, >2 роботов, каждый за себя
• http://www.youtube.com/watch?v=EJPskFGvGi8 — Схватка, стоит обратить внимание на робота Portia (бирюзовый) — это один из лучших бойцов в этой категории