Кое-как с третьей попытки вымучил раздел "Зачем?" главы "Эргономичный подход".
Купили бы книгу с такой постановкой проблемы?:)
———
2.1. Зачем?
Так вышло, что все 20 лет своей карьеры я занимался разработкой "простых" CRUD-приложений.
Они всю свою жизнь (в некоторых случаях - десятилетнюю) хранили данные в реляционной СУБД одного вендора (один раз требовалась поддержка двух вендоров - PostgreSQL и Oracle). Они всю свою жизнь принимали запросы по HTTP и возвращали ответы в формате JSON.
Церемонии Чистой Архитектуры в таких приложениях только мешали.
И в них не было настолько сложной бизнес-логики, чтобы бизнес видел ценность в проведении сессий эвентштроминга с участием экспертов предметной области и трате времени на создание вездесущего языка (Ubiquitous language) и карты контекстов. И они не обслуживали разные отделы бизнеса, с собственными процессами, правилами и языком.
Идея применения DDD в таких приложения умирала на этапе "продажи" бизнесу и команде.
Но назвать эти приложения простыми у меня язык не поворачивается.
Потому что они хранили информацию о десятках и сотнях типов сущностей. У которых были десятки, а иногда и сотни полей.
А "простые" CREATE/UPDATE/DELETE операции затрагивали десятки таблиц, делали пару-тройку походов во внешние сервисы по HTTP, публиковали по сообщению в пару разных брокеров очередей и отправляли емейл "на сладкое".
Сложность этих систем заключалась не в бизнес-правилах и инвариантах, на которых фокусируются Чистая Архитектура и DDD, а в модели данных и взаимодействиях с внешними системами.
И разработчики таких систем оставались без руководства, как проектировать модель данных и эффекты (поведение). И в отсутствии каких-либо ограничений, разработчики шли по пути наименьшего сопротивления и порождали такие модели данных:
Картинка №1
и такие графы вызовов методов:
Картинка №2
Диаграммы выше - это диаграммы построенные по коду реального проекта, с которым мне довелось работать. И я вам скажу, что работать с этим кодом было удовольствием для редкостных гурманов.
На самом деле именно этот проект послужил для меня толчком к поиску способа писать код по другому, который в итоге привёл к созданию Эргономичного подхода и написанию этой книги.
Я создал Эргономичный подход для того, чтобы я сам и другие разработчики "простых" CRUD-приложений могли проектировать сложные модели данных без экспертов предметной области и организовывать код поведения так, чтобы эффекты его работы были очевидными, а задачи по его оптимизации, исправлению и рефакторингу не превращались в детективные триллеры.
#ergo_book@ergonomic_code
Купили бы книгу с такой постановкой проблемы?:)
———
2.1. Зачем?
Так вышло, что все 20 лет своей карьеры я занимался разработкой "простых" CRUD-приложений.
Они всю свою жизнь (в некоторых случаях - десятилетнюю) хранили данные в реляционной СУБД одного вендора (один раз требовалась поддержка двух вендоров - PostgreSQL и Oracle). Они всю свою жизнь принимали запросы по HTTP и возвращали ответы в формате JSON.
Церемонии Чистой Архитектуры в таких приложениях только мешали.
И в них не было настолько сложной бизнес-логики, чтобы бизнес видел ценность в проведении сессий эвентштроминга с участием экспертов предметной области и трате времени на создание вездесущего языка (Ubiquitous language) и карты контекстов. И они не обслуживали разные отделы бизнеса, с собственными процессами, правилами и языком.
Идея применения DDD в таких приложения умирала на этапе "продажи" бизнесу и команде.
Но назвать эти приложения простыми у меня язык не поворачивается.
Потому что они хранили информацию о десятках и сотнях типов сущностей. У которых были десятки, а иногда и сотни полей.
А "простые" CREATE/UPDATE/DELETE операции затрагивали десятки таблиц, делали пару-тройку походов во внешние сервисы по HTTP, публиковали по сообщению в пару разных брокеров очередей и отправляли емейл "на сладкое".
Сложность этих систем заключалась не в бизнес-правилах и инвариантах, на которых фокусируются Чистая Архитектура и DDD, а в модели данных и взаимодействиях с внешними системами.
И разработчики таких систем оставались без руководства, как проектировать модель данных и эффекты (поведение). И в отсутствии каких-либо ограничений, разработчики шли по пути наименьшего сопротивления и порождали такие модели данных:
Картинка №1
и такие графы вызовов методов:
Картинка №2
Диаграммы выше - это диаграммы построенные по коду реального проекта, с которым мне довелось работать. И я вам скажу, что работать с этим кодом было удовольствием для редкостных гурманов.
На самом деле именно этот проект послужил для меня толчком к поиску способа писать код по другому, который в итоге привёл к созданию Эргономичного подхода и написанию этой книги.
Я создал Эргономичный подход для того, чтобы я сам и другие разработчики "простых" CRUD-приложений могли проектировать сложные модели данных без экспертов предметной области и организовывать код поведения так, чтобы эффекты его работы были очевидными, а задачи по его оптимизации, исправлению и рефакторингу не превращались в детективные триллеры.
#ergo_book@ergonomic_code