DMdev talks

#ВашВопрос
👇
Как относишься к гексагональной архитектуре организации кода? Слой сервисов работает исключительно с классами-доменами, что усложняет работу с БД, из-за закрытия сессии на уровне портов.

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

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

Например, на своем проекте я по достоинству оценил лишь отделение интерфейса взаимодействия с приложением, где я пишу код абстрагируясь от протоколов - будь то это HTTP, gRPC, Stubby, и т.д. Все это на себя берут "адаптеры".

Когда же дело доходит до "downstream" зависимостей, которые будут использоваться в бизнес логике (например, базы данных, message brokers), то почти всегда приходится спускаться до нюансов работы инструмента, чтобы работало именно так, как надо, а не так, как получится.

Что касается вопроса - я не вижу большого смысла в усложнении работы с базами данных, потому что:

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

- идея про возможность заменить СУБД на лету только звучит круто, на практике никто этого делать не будет за редким исключением (что только подтвреждает правило).
Данные - это самое важное в приложении, на основании чего потом и рассчитывается перфоманс приложения, и аналитика будет строиться, и LLM обучаться, и т.д.

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

👍25🔥5❤4

www.tgoop.com/dmdev_talks/324

2.89K viewsMar 12 at 15:35

#ВашВопрос
👇
Как относишься к гексагональной архитектуре организации кода? Слой сервисов работает исключительно с классами-доменами, что усложняет работу с БД, из-за закрытия сессии на уровне портов.

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

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

Например, на своем проекте я по достоинству оценил лишь отделение интерфейса взаимодействия с приложением, где я пишу код абстрагируясь от протоколов - будь то это HTTP, gRPC, Stubby, и т.д. Все это на себя берут "адаптеры".

Когда же дело доходит до "downstream" зависимостей, которые будут использоваться в бизнес логике (например, базы данных, message brokers), то почти всегда приходится спускаться до нюансов работы инструмента, чтобы работало именно так, как надо, а не так, как получится.

Что касается вопроса - я не вижу большого смысла в усложнении работы с базами данных, потому что:

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

- идея про возможность заменить СУБД на лету только звучит круто, на практике никто этого делать не будет за редким исключением (что только подтвреждает правило).
Данные - это самое важное в приложении, на основании чего потом и рассчитывается перфоманс приложения, и аналитика будет строиться, и LLM обучаться, и т.д.

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

BY DMdev talks