×

От простого к сложному: путь от монолита к микросервисам

Привет! Я Александр Павленко, PHP Developer в NIX и спикер NIXMultiConf. Уже четыре года занимаюсь этим направлением и часто вижу статьи на тему «Монолит: плюсы и минусы», «Микросервисы: за и против», «Монолит vs микросервисы». И намного реже — о правильных переходах между архитектурными подходами и их взаимодействии. Хотя проекты могут быстро расти или кардинально менять свой курс развития, нужно знать, когда и какой архитектурный подход поможет поддерживать систему.

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

Иллюстрация Алины Самолюк

Выбирая подход, учитывайте все риски

Мировые компании давно используют микросервисы. Например, монолитные приложения Amazon, Coca-Cola и Netflix в какой-то момент переросли в более масштабные инфраструктуры. Брендам такое решение пошло на пользу и привлекло еще больше аудитории. Но тренд не значит, что монолит — это вчерашний день. Мы с командой не привыкли слепо гнаться за новомодными тенденциями. Всегда анализируем, когда тот или иной вариант эффективен и как безопаснее к нему перейти.

Наш проект в сфере финтех строился на монолите. Этот подход напоминает кубик Рубика: если вытащить из него одну деталь, собрать новую форму или добавить другие компоненты, кубик уже не будет полноценно работать. Каждый элемент формирует единый функционал. Если какой-то части не хватает, она сломана или стоит не на месте — цветное поле не сложится.

Почему выбрали монолит? Во-первых, в условиях стартапа с ним удается быстрее запустить проект. Когда условно через месяц надо презентовать клиенту MVP, но ни конкретных требований, ни спецификаций по продукту нет, спасает только монолит. Его гибкость проявляется в разнообразии инструментов, которые можно интегрировать для упрощения разработки. Кроме того, развертывать изменения или обновления можно сразу, а не по отдельности. Во-вторых, на старте монолит легко и быстро масштабировать. Для нашей команды преимущества были очевидны.

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

Наш стартап стремительно развивался. Росло количество пользователей, клиентов, регулярно добавлялся различный функционал. Спустя некоторое время проявились недостатки монолита. То, что было критично для нас:

  • из-за стремительного роста системы становилось сложнее ее поддерживать и развивать без дополнительных ресурсов. Прежде всего это касалось стоимости внесения новых изменений. Чем дальше мы шли и внедряли новые фичи, тем больше они дорожали;
  • рисковали в будущем застрять на старых технологиях. Думаю, многие коллеги сталкивались с legacy-монолитами — за окном 2020 год, а на мониторе в коде 2003-й. Переписывать все это крайне сложно. Обычно не хватает ни времени, ни ресурсов.

К счастью, мы заранее предвидели риски, поэтому переход на новую архитектуру не шокировал. Все прошло плавно и спокойно. Микросервисный подход решил несколько задач.

Многократное использование микросервисов позволило легче адаптироваться под новые требования стартапа и масштабировать его. Теперь мы знаем, что для подготовки MVP лучше взять монолит, а дальше, с ростом проекта, дело за микросервисами.

Внедрять новый функционал без дополнительных затрат и упрощать интеграцию последующих приложений.

Теперь мы уходим от сильной монолитной связанности. Большая часть функций делятся на небольшие независимые группы и реализуются в виде микросервисов. Последующие изменения или новые фичи внедряют внутри такой группы или отдельно в качестве другого микросервиса. При этом не затрагивается ничего лишнего. Что особенно радует: появляется свобода в выборе технологий и языков. У каждого из них есть свои преимущества.

Использовать разные языки программирования под микросервисы и разные виды протоколов для общения между ними.

Но тут же всплыли недостатки. Во-первых, повысился порог вхождения в проект. Во-вторых, усложнилось поддержание, конфигурация и тестирование настроек. По сути, это не является минусом. Главное, что микросервисами закрыли самые важные вопросы.

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

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

Микросервисы хороши и тем, что их можно развертывать и тестировать независимо друг от друга. Это упрощает жизнь команде на всех этапах.

Что микросервисы дали нашему проекту:

  • взаимодействие PHP и Golang. Отлично дополняют друг друга и в некоторых случаях перекрывают слабые стороны. По сравнению с PHP, с помощью Golang можно значительно улучшить перфоманс. За счет параллелизма ускорить обработку и выполнение тех или иных процессов. В то же время у PHP есть все для быстрой реализации удобного CRUD;
  • переход от пяти крупных клиентов к более чем 20 — все благодаря разграничению монолита на отдельные решения;
  • оптимизация нагрузки на сервер. По сравнению с PHP, Golang потребляет намного меньше памяти. С внедрением Golang в проект и переписыванием отдельных частей на Go серверам стало легче. Больше мы с этой проблемой не сталкиваемся;
  • разнообразие команды. Переход к микросервисам — это не только изменение архитектуры кода, но и самой команды. Мы поделились по зонам ответственности. Когда-то нас было пятеро, сейчас около 40 человек. Добавились бэкенд-разработчики и бизнес-аналитики, заточенные под определенные спецификации.

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

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

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

Монолит словно здоровенный котел, в котором варится сразу много всего. С появлением новых «ингредиентов» мы пытались все структурировать. Но помешивая этот «суп», затрагивали другие «ингредиенты», даже когда это не требовалось. Микросервисы помогли создать современную технологическую кухню и разделить зоны функциональности. Мы уже не только «варили», но и «запекали», «кипятили», где-то «жарили», а где-то только «подогревали». Познав тонкости этой высокой кухни, в результате получили качественные продукты.

Монолит или микросервисы: что лучше

Универсального ответа нет, как и окончательного решения. В тех или иных ситуациях бывает логичнее стартовать с монолита. В будущем система может достичь таких масштабов, что переход к микросервисам неизбежен. Из личного опыта я отметил пару сценариев, в которых стоит задуматься о переходе на микросервисы:

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

Иногда мы сталкиваемся с настойчивыми клиентами, которые отказываются от здравой идеи разработчиков. Вот вздумалось заказчику только эту технологию или архитектуру применять. Почему? Да потому что. «Слышал в интернете» или «все так делают». Клиент редко задумывается о подводных камнях, на которые могут наткнуться программисты.

Если вы видите, что есть более эффективный подход, что идея заказчика вызовет новые проблемы или вообще остановит развитие проекта, ваша задача — не бояться сказать клиенту, что он не прав. Объясните, почему лучше использовать ту или иную технологию. Как показывает практика, когда вы можете аргументировать преимущества своей идеи и недостатки предложенного заказчиком решения, он спокойно примет вашу сторону. Проект — это его детище, его деньги, и прежде всего клиент заинтересован в эффективности и прибыльности продукта.

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

Мой основной посыл — не сравнивайте, а подстраивайтесь под особенности проекта и бизнес-задачи. Выбирайте архитектуру приложения взвешенно. Подходящий вариант упростит жизнь вам, команде и пользователям. Да и в целом сделает проект успешнее.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось10
До обраногоВ обраному4
LinkedIn

Схожі статті




Найкращі коментарі пропустити

Очікування: зараз ми швидко і красиво нашинкуємо моноліт на мікросервіси які можна деплоїти незалежно і кожне з яких виконує одну просту функцію.
Реальність: нам треба щоб сервіси однаково писали логи, репортили телеметрію, зберігали секрети, враховували сценарії в яких їх використовують, передавали дані які не використовують іншим сервісам, знали структуру та семантику повідомлень і так далі.
Через короткий проміжок часу: ми запиляли фрейморк для мікросервісів який все це робить... от тільки тепер всі мікросервіси мають бути написані однією мовою з набором бібліотек певних версій, мають деплоїтися у певному порядку і будь-яка зміна в структурах БД чи повідомлень тепер проходить черес майже усі «мікро»-сервіси.
Коли це все нарешті працює в продакшені: щось якось забагато роботи на кожну функцію робити мікросервіс і знову і знову додавати кроки у деплоймент, моніторинг і таке інше — тому будемо дописувати все нове у більше підходящі вже-не-мікро-сервіси.
Через 5 років: у нас легасі моноліт, з нього 30% виділено у мікро-сервіси-моноліти і ми не можемо легко і швидко застосовувати нові мови/фреймворки/бібліотеки. А тому ми зараз їх швиденько поділемо на мікросервіси!

Перед тем как что-то писать, стоит задуматься — скажу ли я что-то новое?
100% этой информации есть в КАЖДОЙ статье касательно микросервисов. Хочется выделиться — добавьте больше информации о личном опыте использования, интересных кейсах, с которыми столкнулись. Иначе это больше похоже на рерайт статей из интернетика для студенческой конференции.

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

Оце от п’ять років я учасник коммюніті JHipster і всі ці п’ять років йдуть холівари на рахунок мікросервісів... На сьогодні JHipster позиціонується як готовий солюшн по мікросервісах і є певні моменти, з якими всі сторони холівару погодилися:

1. Якщо проектом займається лише одна команда — має бути моноліт.
2. Якщо від початку планується використовувати мессадж брокери — Kafka, Solace etc — є сенс в мікросервісах навідь коли команда одна.
3. Так чи інакше все має починатися з архітектури.
4. Мікросервіси — це паттерн, який вирішує певні проблеми. Немає проблем — тоді це антіпатерн.

Переход к микросервисам — это не только изменение архитектуры кода, но и самой команды. [...] Когда-то нас было пятеро, сейчас около 40 человек

Для аутсорса — самое оно =)

40 человек вместо 5 — мечта.
Hint: еще можно каждый сервис на новом языке писать, тогда еще круче будет

297 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

після тренду на мікросервіси кілька років тому в мене підірвалася віра в адекватне сприйняття реальності людьми. Купа проблем була очевидна при одному описі підходу: відмова від зберігання коду в одному місці і доступу туди всіх людей. Ок, припустимо, а костистентнісь як підтримувати, як версійність підтримувати? Дебаг не показав помилку, значить її немає? І звичайно на практиці все це вилазить. Просто кілька сценаріїв: переіменувати проперті, дізнатись як працює код залежності, подивитись логи сусіднього сервісу, видалити метод, дізнатись чи було щось виправлено в залежних сервісах. Ці всі проблеми були очевидними тільки при описі підходу. Такі підходи вигідні тільки аутсорсерам і клауд сервісам, а просувають їх в більшості теоретики, які не в курсі того як відбувається реальна розробка.

Ну там же на початку, ніби, усі були за те, що кожен сервіс робить окрема команда (5-10 людей), і простіше кожній команді дати свій шматок, аніж намагатись їх усіх примусити робить спільну справу.
Ось тут якийсь перелік «як не треба» microservices.io/...​from-monolithic-hell.html

можна уявити середній солюшен 20 проектів розбити на 2 по 10, закинути їх в 2 різні репозиторії і поєднати через json/xml. Спочатку це буде один розробник, і не буде складності з комунікацією. В якому випадку буде більше фейлів? Тепер переходимо від одного розробника до команд 5-10. Малюємо варіанти. А тепер уявити що склеювати до купи це все також будуть треті люди, які не знають деталей ні першого ні другого, обмежені в часі, і яким не можна або складно відмовити.

Сам по собі підхід один великий антипатерн. А систематизація і виділення окремих антипатернів це ще один антипатерн, який полягає в відмові визнати проблему, і переносі відповідальності на виконавців.

середній солюшен 20 проектів

не зрозумів. що є проект? як ці 20 пов’язані?

Ви не знаєте точних умов. Суть в тому щоб сказати що краще, 1 солюшен на 20 проектів, на якому є умовний білд + тести, або 2 солюшени по 10 проектів.

Ну візьмемо пошуковик Гугла.
Там треба:
* Краулєри
* Бекенд пошуковика
* NLP
* Розпізнавання картинок
* Пошукові індекси
* Роботу з рекламодавцями
* Аналітику профілів користувачів для адаптації пошуку
* Аналітику профілів користувачів для контекстної реклами
От я не думаю, що це усе (насправді — що будь-які 2 області з цих) варто ліпити в спільний солюшн, пхать на спільний сервер, чи робить одній команді.
Результат — окремі сервіси.

Не можна сказати що варто або ні запихати в один солюшен. Потрібні деталі. Але точто можна сказати коли що одну схему в одні базі підтримувати простіше ніж 2 схеми в двох базах які посилаються на одні дані. В загальному випадку неможливо навіть пейджинацію зробити. З цього можна картину малювати «адепт мікросервісу пояснює чому не можна заімплементити пейджинацію», з хмарками : гугл, амазон, майкрософт!!!!

В ідеалі — вони не мають посилатись на одні дані.
Саме через проблему роботи зі спільними даними (залежність прийняття рішення від стану кількох підсистем) я ліпив кілька акторів в один.
Але отакий собі гугловий варіант, коли в пошуку за текстом — своя база, в пошуку за картинками — своя, в рекламодавців — своя. Що в ньому поганого чи нелогічного? Бекенд віддасть запит відповідному пошуковому сервісу (текст чи картинки), одночасно спитає рекламний сервіс що показать, і нотифікує трекери поведінки що саме користувач шукає. А коли пошуковий сервіс та реклама нададуть свої відповіді — бекенд їх зліпить докупи й відправить користувачеві.
І при цьому ми взагалі не думали, як там працюють краулери — бекенду воно не треба. А от пошуку за картинками — треба від тих краулерів раз на добу отримувати індекс. То він з ними сам і спілкується, але не думає, як краулить — то інший відділ робить.

погано те що дуже прості сценарії перестають бути такими з мікросервісами. Тут приводили статтю dwmkerr.com/...​oservice-madness-in-2018
Але простіше я вже говорив: 2 менші системи в загальному випадку складніше ніж одна для розробки і деплойменту. При тому значно складніше. Прості сценарії: невідповідність в DTO, пейджинація, невідповідність реквайрментів і коду. В монолітах таких проблем або немає за дизайном або вони вирішуються на етапі компіляції.

На певному етапі моноліт перестане масштабуватись. Наприклад, усі пошукові індекси того ж Гугла не влізуть на одну систему. То вже потрібно шардить. І система вже стала розподіленою. Коли беремо індекс пошуку в тексті та на картинках — то різні індекси, і обидва дуже великі. І нам ліпше розіпхать окремо текстовий, і окремо картинки, ніж зайвий раз різать кожен з них.

Деплоймент краулерів буде геть незалежним від деплойметна пошукового індексу, а пошуковий індекс — від бекенду. Так, там версіонування API треба. Але монолітом його просто тупо не зробиш — забагато даних, і різні домени в різних команд. Так само, як ви не вкомпільовуєте движок бази даних у власний бекенд, а окремо оновлюєте базу, окремо — код. Чому? База при цьому стає одним з сервісів, що деплоїться і розробляється незалежно бекенда. І нічого — усі так живуть.

а окремо оновлюєте базу

бо база має багато фунціоналу для обробки данних.
а як логі писати, то так, можно і у текстові файли.

На певному етапі моноліт перестане масштабуватись

«Нашому теляті да вовка б з’їсти»

бо база має багато фунціоналу для обробки данних.

То чому ж Ви не затягнете цей функціонал в основний солюшн і не почнете деплоїти бекенд разом з базою? Щоб усі проблеми знайшлись на етапі компіляції.

То чому ж Ви не затягнете цей функціонал в основний солюшн

бо його треба — написати. а навіщо його — писати, коли він вже — написаний?

Щоб усі проблеми знайшлись на етапі компіляції.

їх знаходять автори цього функціоналу.
і сапортять його, випускаючі оновлені версії.
теж саме і з головним фреймворком, і лібами.

теж саме і з іншими — а чого не пишуть самі ребітів або кафку?
ну й затягнули б у мікросервіс.

їх знаходять автори цього функціоналу.
і сапортять його, випускаючі оновлені версії.
теж саме і з головним фреймворком, і лібами.

То ось Ви й відповіли, навіщо мікросервіси.
Щоб кожна команда сапортила свій функціонал.

То ось Ви й відповіли, навіщо мікросервіси.

не відповів.
код сервісів ми не пишемо.
ми беремо бінарні версії сервісів.

Щоб кожна команда сапортила свій функціонал.

зо всіма складнощами менеджменту, девопсу, і іншим, що надав у цієї темі.

кожна команда так само може писати і сапортити — свої модулі, плагіни і т.і.
про це вже писалося: якщо команди можуть працювати по спєках мікросервісних API — то чому вони не можуть писати по спєках внутрішніх у моноліті API?

Бо моноліт може не влазити в один бокс, одна операція в моноліті може буть занадто довгою, база моноліта може занадто роздутись, певні шматки може буть зручнішим писать на різним мовах чи в різних парадигмах, і якщо один модуль впаде — потягне увесь моноліт, котрий потім довго буде підійматись, а бізнес — втрачати гроші.

+ в моноліті усім командам треба домовлятись про зміни, бо спільні системні ресурси та спільні гайдлайни кодування. А команди в різних часових зонах. Бачили проекти з мітингами, може?

Достатньо?

Бо моноліт може не влазити в один бокс,

а може й влазити.

одна операція в моноліті може буть занадто довгою

яка саме і чому вона заважає іншим операціям?
а, забув, у вас однопоток — в який ви себе загнали :)

певні шматки може буть зручнішим писать на різним мовах чи в різних парадигмах,

а може й не зручніше. хоча б тому що взаємодопомоги тоді не буде.

і якщо один модуль впаде — потягне увесь моноліт,

а це як напишите, може потягне, але як треба щоб не потягнув, то пишіть так що не тягнув. Eclipse та Netbeans — не падають, коли в якомусь плагіні помилка. і оновлються — плагінно.

в моноліті усім командам треба домовлятись про зміни

а у мікросервісах — не треба?

і навіщо — усім?
от навіть до вордпресу пишуть купу плагінів. і що. вони всі, автори домовляються?

бо спільні системні ресурси та спільні гайдлайни кодування

ну так, як маєте можливість — то кожній команді по дата центру дайте :)

Бачили проекти з мітингами, може?

бачив звісно. частенько незрозуміло навіщо вони потрібні.

Достатньо?

чого достатньо — вигадування проблем гугла?

а може й влазити.

Тоді у Вас особисто нема цієї проблеми. А от коли потрібно МЛ робить — то не думаю, що Вам заманеться гонять звичайний бекенд на машинах з дорогими відяшками. От Вам і розділення за залізом.

яка саме і чому вона заважає іншим операціям?
а, забув, у вас однопоток — в який ви себе загнали :)

Бо на Ваш модуль підписані інші модулі, ви кажете NotifySubscribers(myevent), а скількі мілісекунд він буде нотифікувати — ніхто не знає. Може, інший модуль в колбеці в базу полізе й заблокується. Як Ви від цього вбережетесь?

а може й не зручніше. хоча б тому що взаємодопомоги тоді не буде.

А яку взаємодопомогу Ваш джаваскрипт надасть машинному навчанню чи коду об’єднання пошукових векторів?

а це як напишите, може потягне, але як треба щоб не потягнув, то пишіть так що не тягнув. Eclipse та Netbeans — не падають, коли в якомусь плагіні помилка. і оновлються — плагінно.

Значить, вони породжують процеси. І тут Ви отримуєте купу проблем, схожих на мікросервісні — і серіалізацію даних, і конфлікт версій — усе, чого Ви так боялись.

а у мікросервісах — не треба?

В мікросервісах локальні зміни (що не чіпають інтерфейс) не впливають на сусідні сервіси. А в моноліті одна команда вижерла оперативу — і моноліт захлинувся. Чи хтось заспамив спільну базу.

і навіщо — усім?
от навіть до вордпресу пишуть купу плагінів. і що. вони всі, автори домовляються?

А ці плагіни часто користуються один одним? І якщо вордпрес впаде чи зависне — скільки грошей це коштуватиме?

ну так, як маєте можливість — то кожній команді по дата центру дайте :)

От ті, хто мають — і займаються мікросервісами) І чомусь не жаліються)

чого достатньо — вигадування проблем гугла?

То як Ви не маєте таких проблем — навіщо Вам ті мікросервіси. Живіть собі спокійно в своєму затишному світі.
І не розповідайте Гуглу що йому його мікросервіси лише шкодять.

То як Ви не маєте таких проблем — навіщо Вам ті
мікросервіси.

От про те й пишуть і у цій темі, і у статтях що наводили.
Вітаю що вас осяла ця ідея — що хтось не має таких проблем щоб пити ліки від них :)

І не розповідайте
Гуглу

Я на доу. Мене в радники гугл не кликав, та я б точно відповів би що то помилка якась. Але так, я постійно забуваю що тут основна маса колег — програмісти у гуглі, та ще й на посадах архітекторів.

І тут Ви отримуєте купу проблем, схожих на мікросервісні — і серіалізацію даних, і конфлікт версій — усе, чого Ви так боялись.

То навіщо мені ті ж самі проблеми з додатком мікросервісних? Я ж не гугл.

А яку взаємодопомогу Ваш джаваскрипт надасть машинному навчанню чи коду об’єднання пошукових векторів?

Не знаю що це. Не зтикався, як і більшість програмістів світу

А в моноліті одна команда вижерла оперативу

Ай облиште розповідати про жахіття цієї проблеми. Буває звісно, але вирішення не потребує рокет саєнсу. Як і більшість інших — багів.

Чи хтось заспамив
спільну базу.

І хто ж цей хтось — не знайти ніяк... А мікросервіси неможна заспамити, щоб їх інстанси не почали множитися по сценарію пікового навантаження до виїдання усіх ресурсів як то було нещодавна у гугла та cloudflare?

Не знаю що це. Не зтикався, як і більшість програмістів світу

Мені треба було по роботі почитать трохи nlp.stanford.edu/...​ng-it-all-together-1.html

Ай облиште розповідати про жахіття цієї проблеми. Буває звісно, але вирішення не потребує рокет саєнсу. Як і більшість інших — багів.

Більше часу, і більший сервер треба. А мікросервіси живуть — кожен на свому меншому.

А мікросервіси неможна заспамити, щоб їх інстанси не почали множитися по сценарію пікового навантаження до виїдання усіх ресурсів як то було нещодавна у гугла та cloudflare?

Один виїсть ресурси на своїй машині, а інші житимуть якось. І його один відкатять і віддебажать. А от в моноліті знайти де підтікає — трохи (чи не так щоб трохи) важче. І якщо моноліт відкотили — то усі нові фічі й багфікси в усій конторі також, і можна буде щось нове робить чи латать лише коли лік знайдеться і виправиться.
Такое.

Такое

Ой лишенько, і як же ті легасі системи живуть роками, і задовільняють потреби бізнесу. І як оті сапи аг заробляють роками...

І як же оті потвори на php у топ попадають
Best e-commerce platforms

Коли ж накінець світ зрозуміє якє щастя усім і бізнесу і програмістам — мікросервіси.

Вам вистачає php на одному сервері — то й радійте, що файно є.
Не вистачить — перепишете або на мікросервісах, або на С++.

Не вистачить

php прекрасно масштабується на купу серверів.
бо немає «application in memory» (в нього і пам’ять не тече, і він не зависає. і навіть баг у модулі — не крашить всю систему, а тільки оцей особливий запит — його цей недолік, відсутніть аплікації, і є його унікальна перевага)

хоча й ті що мають — там с деплойментом тільки трохі складніша автоматика — балансер вимикає інстанси що будут оновлюватися, а потім перемикає на оновлені.

у php є інші недоліки, які так, можуть привести до відмнови від нього
але не заради «не вистачає одного серверу».

те ж саме з БД
як хлопці на одному щось на кшалт мастер класу по Cassandra сказали
«якщо відверто, то половині наших замовникив вона була непотрібна. вистачило б постгрі та відомих засобів горизонтального масштабування. але вони хтіли тих проблем, та й ми напрацьовуємо експертизу на її особливостях...»

або на С++.

це буде щось неймовірне. такого ще не чув :)
джава/.net — так, буває :)

Діскорд якось на Rust, з Go, переписав один з сервісів. але щоб на С++... то точно треба бути хоча б яндексом

э отакє вимирювання
www.techempower.com/...​data-r19&hw=ph&test=query

і якщо узагальнити, дивитись як на тренд, і не звертати уваги на деякі виключення
то висновок такий виходить:
чим менша швидкодія — тим більша популярність використання, бо там чим нижче — тим більш популярна, поширена технологія.
(звісно це жартівливий, але, але...)

Чомусь ebay не додумався...
www.slideshare.net/...​city-performance-and-cost
Чи тоді ще php не було?

Чомусь ebay не додумався...
...Чи тоді ще php не було?

в якому році стартували?
плюс — є місцеві традиції. цимало стартапів тоді стартувало на рубі. той же твітер з нього починав.

а от купа москальских компаній, місцевих „ebay” — так на php і живуть.

і знову таки — ви займатетесь демагогігею
компаній рівня ебай, або аліекспрес — 0.0... %

а в реаліях світу, ось
www.statista.com/...​e-platforms-market-share

або от
Ecommerce Platforms Market Share Statistics in 2021

In the US, WooCommerce takes up 23% of ecommerce platforms market share, followed closely by Shopify (21%) and Wix (15%). (Oberlo, 2020)
48% of online shoppers navigate straight to a large ecommerce marketplace when buying something online. (Big Commerce)
Shopify powers more than one million merchants in over 175 countries, and has processed a massive $172 billion in sales to date. (Shopify)
WordPress powers a whopping 36% of websites. (WordPress)
Wix helps more than 150 million users in 190 countries around the world to start their website. (Wix)
There are as many as 820,000 stores hosted with Shopify. (SimilarTech)
Printify, a print on demand solution, boasts a solid 300,000 number of clients. (Printify)
Ecwid claims to have 70,000 active shops open with them. (Ecwid)
Sellfy, an ecommerce platform to sell digital products, has as many as 20,000 active stores open. (Sellfy)
More than 17,000 creators chose Podia for selling online courses, digital downloads and memberships. (Podia)
Over 40,000 creators are selling their digital products using Gumroad. (Gumroad)
WordPress powered ecommerce platform WooCommerce claims to host an absolutely majority of stores online, with 840,000 stores. (SimilarTech) (Source: letstalkaboutmoney.com/ecommerce-statistics)

Що це доводить? Що мікросервіси шкодять ebay чи Гуглу, тому від них потрібно відмовитись і перейти на php?

Що це доводить?

що «эвангелісти» чогось хайпового частенько опираються на «аргумент блондинки»: а от я знаю випадок!

тому від них потрібно відмовитись і перейти на php?

і на ще відомий демагогічний ход
зведення до абсурду

а чому? тому що раціональних аргументів не мають :)

Ну то зверніться до авторитетів
martinfowler.com/...​oservice-verdict/path.png
а не кажіть, що мікросервіси нікому не потрібні
en.wikipedia.org/...​le:Hype-Cycle-General.png

Ну то зверніться до авторитетів

демагогія:
Апелляция к авторитету (лат. Argumentum ad verecundiam — «аргумент к скромности») — вид оспаривания аргументаций, предложение считать некоторое утверждение корректным потому, что такое утверждение сделано неким источником, считающимся авторитетным.

а не кажіть, що мікросервіси нікому не потрібні

Подмена тезиса (лат. ignoratio elenchi) — логическая ошибка и один из демагогических приёмов, основанных на опровержении фиктивной точки зрения с целью обоснования другого утверждения.
(де це я казав — «нікому не потрібні»?

на тому і закінчемо, така банальна демагогія не цікава ніяк.

Більше часу, і більший сервер треба. А мікросервіси живуть — кожен на свому меншому.

Ну это такой себе аргумент. Поддерживать весь этот зоопарк чтобы очередной «архитектор» деплоил в отдельный контейнер какуюто отдельную функцию — тот еще оверхед.

Поддерживать, если база в бокс не влазит и не шардится. Или приложение сильносвязное, и не влазит в проц.
Или — когда 200 человек работают в одном репозитории.

в моноліті усім командам треба домовлятись про зміни
Бо моноліт може не влазити в один бокс,

особливо ці два аргументи про-мс мене радують. Як можна не розуміти що при мс домовлятись потрібно набагато більше і ’якісніше’, з меншим набором інструментів і з набагато більшою вірогідністю щось може піти не так.

а не влазити в один бокс... не знаю в скількох % проектів розмір артифактів dll має значення. Це мають бути гігабайти dll. Ніхто не згадує про кеш і лоад балансери.

особливо ці два аргументи про-мс мене радують. Як можна не розуміти що при мс домовлятись потрібно набагато більше і ’якісніше’, з меншим набором інструментів і з набагато більшою вірогідністю щось може піти не так.

В микросервисах если код тормозит на вызове — он тормозит только себя. В монолите этот код затормозит того, кто его синхронно вызвал, и того, кто вызвал того, кто его вызвал. В результате, ты делая свой модуль должен понимать, куда идут синхронные вызовы между модулями и где и насколько они затормозят. А еще можно вспомнить дедлоки.

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

а не влазити в один бокс... не знаю в скількох % проектів розмір артифактів dll має значення. Це мають бути гігабайти dll. Ніхто не згадує про кеш і лоад балансери.

Має значення не розмір коду, а оперативка та проц. В моноліті купа модулів завантажені, кожний тримає свій стан.

Має значення не розмір коду, а оперативка та проц. В моноліті купа модулів завантажені, кожний тримає свій стан.

ок. я горизонтально масштабую моноліт через лоад балансер. Завантажую ті модулі які хочу на кожній ноді. Що мені заважає?

ок. я горизонтально масштабую моноліт через лоад балансер. Завантажую ті модулі які хочу на кожній ноді. Що мені заважає?

Те, що ці модулі без інших модулів неробочі)))

в мене моноліт, і тому все консистентно. всі модулі робочі і працюють. Навантаження на систему я знімаю лоад балансером. Де я зекономлю на мікросервісах? 150 МБ жорсткого диску ? ) Модуль навіть не завантажується в пам’ять якщо його не використовувати. Не говорячи про CPU. Виходить я трохи місця на жорсткому диску зекономив?

Модуль навіть не завантажується в пам’ять якщо його не використовувати.

А скільки часу він завантажується, коли потрібен? Я думав, люди тримають усе готове до роботи під FCGI.

Тим більше, коли модулі не викликають один одного — то це вже не моноліт, ніби. А купа окремих незалежних скриптів.

Де я зекономлю на мікросервісах?

На мікросервісах не економлять. Вони дорогі й неефективні. Але коли не можна масштабувати людей чи ресурси інакше — то без варіантів.

Як можна не розуміти що при мс домовлятись потрібно набагато більше і ’якісніше’, з меншим набором інструментів і з набагато більшою вірогідністю щось може піти не так.

А ще є такий цікавий процес, як зміна інтерфейсу. В моноліті, зазвичай, здається, інтерфейси не версіоновані. Відповідно, щоб змінити інтерфейс модуля, команда має домовитись з усіма іншими командами, що його використовують, і одночасно провести й закомітити зміни. Легко зробити таке, скажімо, для 5 команд, в кожної з котрих горять свої задачі?

А ще — такий цікавий процес, як зміна типів даних чи класів, що використовуються багатьма модулями. Як у відомих Вам проектах з багатьма командами роблять такі зміни?

А ще є такий цікавий процес, як зміна інтерфейсу. В моноліті, зазвичай, здається, інтерфейси не версіоновані.

в моноліті більшіть інтерфейсів працюють через пам’ять а не мережу. Версіонування їх не потрібне, тому що консистентність таких інтерфейсів зашита на рівні коду. Є компілятор який стежить за цим.

Відповідно, щоб змінити інтерфейс модуля, команда має домовитись з усіма іншими командами, що його використовують, і одночасно провести й закомітити зміни. Легко зробити таке, скажімо, для 5 команд, в кожної з котрих горять свої задачі?

Це може зробити одна людина, зробивши зміни в усі модулі. Запустивши білд, тести і почитавши код навіть одна людина зможе це зробити.
З мікросервісами ви маєте іншу команду, код який не знаєте і набір інтерфейсів. Блекбокс. Якщо хочете деталей — пишети листи.

Це може зробити одна людина, зробивши зміни в усі модулі.

Для цього одна людина має знати, як оті усі модулі працюють. А потім — мержи та пулл реквести та код ревью. І треш затягнеться на тиждень на рівному місці.

З мікросервісами ви маєте іншу команду, код який не знаєте і набір інтерфейсів. Блекбокс.

З мікросервісами в чужий код ніхто не лізе. Робиться нова версія API і паралельно лишається стара робочою. Кому треба нова фіча — сам переходить на нове API.

Якщо хочете деталей — пишети листи.

Для цього існує планування між лідами (на зразок скраму скрамів). І коли станеться, що одна команда тримає іншу — то вирішується керівником проекта, котрий керує усіма лідами, і відповідає за фічі перед бізнесом.

Для цього одна людина має знати, як оті усі модулі працюють. А потім — мержи та пулл реквести та код ревью. І треш затягнеться на тиждень на рівному місці.

це був найпростіший синтетичний приклад. В найпростішому випадку коли в людини є код вона зможе розібратися. Трохи складніший — подивитись в коді хто працював з функціоналом і запитати поради, наприклад додавши в пулл реквест, ще складніший варіант — написати частину коду самому і запитавши відразу деталі по незрозумілій частині, і т.д.

В мікросервісах всі умовні 50% делегуються відразу іншій команді, в якій свої пріорітети, і в найпростішому випадку в Вас задача сформулювати вимоги, і домовитись з іншою командою і чекати. В складніший — гра в пінгпонг і поламаний телефон.

це був найпростіший синтетичний приклад. В найпростішому випадку коли в людини є код вона зможе розібратися. Трохи складніший — подивитись в коді хто працював з функціоналом і запитати поради, наприклад додавши в пулл реквест, ще складніший варіант — написати частину коду самому і запитавши відразу деталі по незрозумілій частині, і т.д.

А те, що потрібно одноразово одним комітом зміни накатать на увесь проект? А якщо маєте автотести — вони мають пройти з цими змінами. А поки вони пройдуть кілька годин — хтось в якомусь модулі вмержиться в мастер, буде конфлікт, і усе спочатку робить.

В мікросервісах всі умовні 50% делегуються відразу іншій команді, в якій свої пріорітети, і в найпростішому випадку в Вас задача сформулювати вимоги, і домовитись з іншою командою і чекати. В складніший — гра в пінгпонг і поламаний телефон.

В мікросервісах домовлятись не потрібно.
Варіанти, що я наводив:
1) Зміна інтерфейса сервісу. Робиш новий інтерфейс, але лишаєш паралельно стару версію. Кому треба нова фіча — юзає новий інтерфейс, кому ні — продовжує зі старим.
2) Зміна глобальних типів даних. А нема таких! А в себе в сервісі міняй що хочеш — тільки інтерфейс старий підтримуй.

Якщо начальство хоче фічу — воно й домовляється з усіма командами, сервіси яких цю фічу імплементують.

Ты немношк путаешь теплое с мягким. В базе миллионы строк кода, она пишется годами.
Микросервис — это «ясделяль» от мамкиного архитектора, который решил что квери к вот этой табличке пойдут через отдельный сервис потому что атомарно, скалабельно, и прочий микросервис булшит.

Откуда определение? Из книжек по микросервисам?
Там, вроде, говорили, что микросервис — это когда команда 5-10 человек делает свой кусок как хочет, и у нее свой сервер, куда это деплоится. Все, типа. А, ну еще, в идеале, оно не делает RPC и не шарит базу с соседями, и защищено гексагоналкой (anti-corruption layer).
Microservice Patterns, Richardson, 2018

Микросервис и не должен думать об атомарности например. Этим занимаются совсем другие части всего солюшена, оркестрирующие те же распределенные транзакции, как в SAGA. Микросервис должен поддерживать определенные команды для тех же транзакций, содержать idempotent операции, быть fault tolerant, поддерживать общую трассировку и логирование, обеспечивать обратную совместимость и версионность.
Конечно, если писать микросервисы через жопу и распиливать солюшен на микросервисы через жопу, то результат будет ожидаемо через жопу.

як краулить — то інший відділ робить.

в нас теж краулер є.
для даних — що треба для бізнес-логіки.
тому він майже нічого і не парсить, то просто нода з Puppeteer, щоб js скрипти виконувались.
а вся робота — записи у ту же базу, бо данні — однакові, або доповнються, агрегуються з різних джерел.
і яка може бути окрема база — коли результат — такіж самі данні які б заносив оператор руками.
тому цю часитину — залишили у моноліті. бо дублювати бізнес логіку — то тра команду «у два рази» збільшувати.

В ідеалі — вони не мають посилатись на одні дані.

якщо це різні данні — то можна їх тримати окремо.
якщо це ті ж самі данні — то тримати окремо — собі роботу придумувати.

Думаю, ваш краулер трохи не парсить весь інтернет, і трохи не робить стемінг та кластеризацію слів та текстів. Коли б робив — js було б замало.

Думаю, ваш краулер трохи не парсить весь інтернет, і трохи не робить стемінг

так, у нас немає потреби ставати гуглом № 2 :)

як і у 99.9% бізнесів.

і трохи не робить стемінг та кластеризацію слів та текстів

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

тобто — не треба вигадувати де данні субдоменів — воно само якось виходить, що це — окремі данні. а як не виходить — то навряд чи вони — окремі, і після того як їх силоміць розтягли по окремих БД, тра думати як це потім їх об’єднати.

а «гугл» як приклад — то як на мене, то тип демагогії, або premature optimization
бо як більшість стартапів — провалиться, так і більшість бізнесів — ніколи й близько не стануть за розміром=проблемами як гугл.
а як будуть наближатится, то поступово й вирішуватимуть проблеми що виникають.

Ну от, як мінімум, в нас тут живуть Рінг та Депозитфотос. Де вже одна база з js давно не прокатує.

В загальному випадку неможливо навіть пейджинацію зробити.

Дублирование данных или не резать. Но какое там может быть дублирование данных, если Вы собираетесь свои «микросервисы» сшивать синхронными запросами...)

Ну візьмемо пошуковик Гугла

не візьмемо. бо ніхто не дасть грошей на все відразу
Краулєри, NLP, Розпізнавання картинок, ..., ...,

От я не думаю, що це усе

ну, як вам дали вже цю купу грошей, та сотні програмістів, то так — проектуйте «гугл № 2»

про те й мова — що у архітектів ум за розум частенько заходить, і вони починають проектувати якийсь гугл, або систему для ТНК

але зазвичай все навпаки, і починалося як фейсбук, якийсь цукерберг наляпав якихось php скриптів.

гугл не тому Гугл що в них Краулєри, NLP, Розпізнавання картинок, ..., ...,
спочатку станьте гуглом, а потім вирішуйте проблеми такого масштабу.

Результат — окремі сервіси.

ні.
результат — пусті розмови ні про що. рівня — як би я мав мільярд долярів, то я б...

а як босота наслухається отієї маячні, то й виходить:
хабр Как мы случайно сожгли $72 000 за два часа в Google Cloud Platform и чуть не обанкротились
We Burnt $72K testing Firebase + Cloud Run and almost went Bankrupt
blog.tomilkieway.com/72k-1

в мене приятель був у стартапі що починали з Google Cloud
дуже швидко виявилось що тра економити запити. а потім ще, ще.
і перейшли вони в результаті на звичайний такий Postgerss, і звичайні дедіки, а не отой serverless. два сервіси — один моноліт(на джаві зі спрінгом), другий на ноді відео роздавав, та вебсокети тримав, щось до 5 інстансів.
через 2 роки правда система грошей так і не почала заробляти, але то вже бізнесова історія.
продукт же вийшов, і відповідав функціональним вимогам, у тому числі і по швидкодії, з запасом.

То что ты описал — это не «микросервисы». Это гига-SOA.

Ну опиши отличие)

Условие резать или нет зависит не от размера, а от функций и (саб)домена как прямых технических факторов + факторов корпоративного контекста. Универсального рецепта нет — может, вообще не надо резать ничего, и микросервисы тоже не надо. Но местная мода приписывать подход «сделали криво» как дефолт как минимум улыбает.

Расскажи Фаулеру
Almost all the successful microservice stories have started with a monolith that got too big and was broken up
Almost all the cases where I’ve heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.
martinfowler.com/bliki/MonolithFirst.html

и Ричардсону
Using the microservice architecture makes it much more difficult to iterate rapidly. A
startup should almost certainly begin with a monolithic application.
[Microservices Patterns, chapter 1]

Похоже, „сделали криво” не только здесь и у нас

Они пишут о других причинах — в основном, о том, что bounded context в самом начале очень сложно определить, и это правда, и я сам на этом местами обжигался. Здесь же предлагают банально делать квадратные колёса, а квадратные колёса сами по себе зафейлят что угодно).

Ну да, не без этого)))

bounded context в самом начале очень сложно определить

ну да. бизнес-логика она такая, сроди «женской в ПМС».
и поэтому чем на более позднюю фазу можно отложить отлив в бетоне инженерной конструкции — тем лучше.
KISS и YAGNI — хорошее подспорье при анализе и проектировании систем в которых бизнес-логика самая значимая часть.

Начиная с сбора требований, учесть что:
а это как у вас?
да, как, как... как у всех (скорее всего будет уникальным в действительности)
а вот это как у вас?
о, это наша фирменная, уникальная фишка (скорее всего будет как у всех)

надо это переслать приводящим в примеры «две компании» и гугл с ебаем, о

it has ended up in serious trouble

и

Using the microservice architecture makes it much more difficult to iterate rapidly

А почитать текст?
Там о крупных компаниях, упершихся в лимит по сложности или производительности, или о стартапах?

А почитать текст?

читал, давно, и не раз и не только у них.

Там о крупных компаниях

а читать что я писал, было влом?
где я все время говорил что подходы компаний из топ 500 форбс — скорее очень вредны чем полезны не входящим в этот топ?

«две компании»

Ринг и Депозитфотос

не слышал о таких. про гугл да, слышал, про эти — не слышал.
и два случая против 10ков тысяч — ни ап чём.

Эти в Украине делаются. А Вы говорите, что украинским разработчикам хайлоад и микросервисы не надо. Странно получается.

где я все время говорил что подходы компаний из топ 500 форбс — скорее очень вредны чем полезны не входящим в этот топ?

Еще в геймдеве, скорее всего, хай лоад есть

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

приведите где я такое говорил.

Еще в геймдеве,

геймдев — не «энтерпрайз»
«энтерпрайз», как вот есть вакансии и у GameLoft — «Требуется программист на php, для разработки и сопровождения внутренней ERP+CRM системы»
одного даже заочно знаю, перешел к ним с продуктовой компании — продукт — эл магаз, CRM, CRM платформа.

вы как глухой, право слово. постов не читаете. хню какую-то мне приписываете.
демагог или просто — не читаете?

И Розетка наверняка тоже до него дожила

не дожила вроде.
у меня был как-то доступ к их репозиторию и доке.
движок OWOX — сродни Маджентовскому, на php

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

«монолит» — это такое же соломенное чучело как и «водопад»

И при чём там микросервисы, позвольте спросить, если Вы их собираетесь

поєднати через json/xml

?

Сам по собі підхід один великий антипатерн.

Ну, если собираться с самого начала делать распределённый монолит, то...)

Для того, чтобы понять откуда вылезли микросервисы нужно понимать контекст реального мира и проблемы, которые микросервисы решают.
Все исходит из нагрузки сервисов и количества пользователей. У всяких гуглов-амазонов эти проблемы возникли еще в 2000-х, у компаний поменьше в 2010-х. Когда нагрузка превышала возможности любой самой дорогой машины — пришлось делить на несколько машин. А еще есть вопрос доступности и надежности — отсюда реплики и по базам и по сервисам. Отсюда новая модель коммуникации — когда-то RPC через раньше всякие dcom, cobra, но со временем через http с помощью xml/json/protobuf. Отсюда вопросы что делать когда один из сервисов отвалился, как обеспечить устойчивость системы — нужны реплики, нужны новая модель коммуникации — messaging — позволяющий избежать частых проблем коммуникации через сетевые запросы.
Оттуда же ростут noSql, потому что Sql — узкое место, которое тяжело скейлить горизонтально, а возможности вертикального скейлинга очень быстро заканчиваются.
У одного сервиса нагрузка 1K в секунду, у второго 1M в секунду. Для 1M нужна нужно 100 машин, а для 1К достаточно 1 и 1 реплики. А когда таких разных сервисов сотня? их все на одну машину пихать и реплицировать на другие сотни машин? Это очень неэффективная модель.

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

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

Отсюда и выплывает необходимость микросервисов — иначе просто невозможно обеспечить необходимую нагрузку.

именно.
поэтому когда такой нагрузки нет — не берите дорогие технологии для таких нагрузок.
и не рассказывайте байки «а вот у гугл, а вот у ебай»

Оттуда же ростут noSql, потому что Sql — узкое место, которое тяжело скейлить горизонтально, а возможности вертикального скейлинга очень быстро заканчиваются.

статистика использования показывает что основными по прежнему остаются рсубд.
а хайп вокруг noSQL — давно прошел.

А когда таких разных сервисов сотня?

а когда — тысяча? и стопицот?
зачем мелочится то, давайте сразу примеры — для стопицот сервисов.

Это уже проблемы второго порядка.

когда нет проблем 1го порядка, то это и проблемы — 1го порядка.

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

ну так понимайте. есть очень крупные компании которым типичные решения — не подходят.
и все. то есть есть проблемы которых нет у средних и мелких компаний.

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

поэтому когда такой нагрузки нет — не берите дорогие технологии для таких нагрузок.

Какая книжка по микросервисам рекомендует наоборот?

Какая книжка по микросервисам рекомендует наоборот?

не книжка. а упоротые :) или далекие.
в книжках больмень обычно.

о том и обсуждение.
очередное.
за годы я их видел уже.

обычная картина — практики, реалисты говорят о том что Х — избыточная технология, и если и решает массовую проблему Z — то вырезанием гландов через анальное отверстие.
упоротые или далекие начинают рассказывать про гуглы, и прочие звездные крейсеры Галактика

такая же картина была про noSQL которые вот-вот убъют реляционки
Про ФП — периодически. и т.п.
про SPA — которые заменят весь веб

обычная картина — практики, реалисты говорят о том что Х — избыточная технология
упоротые или далекие начинают рассказывать про гуглы, и прочие звездные крейсеры Галактика

Избыточная для кого? Я уже назвал две конторы с дев офисами в Украине, для которых обычные технологии не держат нагрузку. Предлагаете им пересесть на php и SQL, чтобы не разрушать Ваш мир, в котором высоконагруженным системам нет места?

Вам в «энтерпрайзе» гексагональная архитектура с защитой от железа кажется бредом, а мне она очень пригодилась в эмбедеде. Может, энтерпрайз не сильно энтерпрайз, или что? Эмбедед не эмбедед получается?

Я уже назвал две конторы

сколько контор — в мире?

Предлагаете им пересесть

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

Вам в «энтерпрайзе» гексагональная архитектура с защитой от железа кажется бредом

не мне, а исходя из апробированных методов.

а мне она очень пригодилась в эмбедеде

эмбедед — НЕ «энтерпрайз»
Почти никогда во всей литературе, посвящённой программированию и разработке программного обеспечения, не упоминается нечто важное, из-за чего мы иногда недопонимаем друг друга... Joel Spolsky

Статья Джоэла о Пяти мирах (программного обеспечения) вышла в 2002 году. За прошедшие 14 лет успели образоваться новые миры: Мобильные приложения и Облака, — но соль статьи осталась неизменной.

Одна и та же технология в разных условиях будет давать разную эффективность.
www.pvsm.ru/cat/joel-spolsky

I think there are five worlds here, sometimes intersecting, often not. The five are:
Shrinkwrap <-
Internal <-
Embedded
Games
Throwaway
www.joelonsoftware.com/2002/05/06/five-worlds

Микросервисный подход решил несколько задач.
Внедрять новый функционал без дополнительных затрат и упрощать интеграцию последующих приложений.
Использовать разные языки программирования под микросервисы и разные виды протоколов для общения между ними.
Главное, что микросервисами закрыли самые важные вопросы.

имею опыт работы в гетерогенных систем где-то на уровне скаже «под архитектора» и вот я читал и думал думал думал что-то тут упускается вот конкретно в этой статье что в частности «сквозит» в комментах

и вот вопрос а как вы решаете «вертикальные» задачи? т.е. как реализуете бизне фичи?

вся эта внутренность она на самом деле сугубо техническая вроде того на каком языке написан монолит или отдельный сервис для бизнеса т.е. для задач решаемых «программных комплексом» это не на столько и важно у бизнеса задачи другие

скажем «вертикальная задача» добавить возможность сравнения товаров просто чтобы грубо обсуждать что-то конкретное скажем некий вариант интернет магазина и вот как она будет реализовываться в условиях описанного микросервисного подхода именно организационно на уровне команд проектов постановки задач отслеживания прогресса и т.д.

Что микросервисы дали нашему проекту:
разнообразие команды. Переход к микросервисам — это не только изменение архитектуры кода, но и самой команды. Мы поделились по зонам ответственности. Когда-то нас было пятеро, сейчас около 40 человек. Добавились бэкенд-разработчики и бизнес-аналитики, заточенные под определенные спецификации.

это всё круто но как именно это работает? к.м.к. вы упускаете одну из самых интересных часть либо как вариант «рабочей гипотезы» вы её просто «не проходили» на самом деле реализовав только задачу «от монолита к микросервисам» а как дальше оно будет работать уже не столь актуально ))

но это просто «рабочая гипотеза» пытающаяся объяснить почему в описании нет описания как раз уже организации работы уже по фичам уже после того как микросервисы полностью внедрены

ЗЫ: к монолиту те же ж вопросы ровно так же ж прекрасно относятся но положим монолит в контексте это совсем другая история а здесь интересно конкретно за микросервисы

Дисклеймер: всё написанное далее ИМХО (которое «хрен оспоришь»).

скажем «вертикальная задача» добавить возможность сравнения товаров

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

Разница между SOA и микросервисами в том, что в SOA отдельные монолиты проектируются отдельно в рамках энтерпрайза, а микросервисы в рамках одного приложения проектируются вместе. Хотя ниже писали, что в SOA никто не мешает использовать асинхронную коммуникацию, но всё-таки в случае SOA в 99% будет присутствовать синхронная коммуникация, потому что подход SOA — это, грубо говоря, способ дать всему энтерпрайзу интерфейс к твоему монолиту, чтобы читать его данные или выполнять какую-то работу, т.к. данные между монолитами в SOA в общем случае не дублируются, и кроме твоего монолита их больше нигде нет (разве что в business intelligence). Поэтому сильная связность в SOA практически без вариантов, и по той же причине я бы назвал дублирование данных основной отличительной особенностью микросервисов от SOA, т.к. она позволяет достичь самостоятельности каждого микросервиса, но отсюда же eventual consistency и другие проблемы. Самая большая сложность состоит в том, чтобы сбалансировать гранулярность.

Т.о., микросервисы — это когда мы режем решение на части так, чтобы необходимость дублирования данных была как можно меньше (т.е., микросервис выполнял как можно более «самостоятельный» сет функций/относился к отдельному сабдомену/you name it), и стараемся при этом минимизировать риск того, чтобы в будущем это дублирование практически не увеличивалось с добавлением новых фич (т.е., чтобы мы не порезали слишком мелко, и тем самым не заработали себе вагон проблем вместо future-proof решения). Поэтому rule of thumb при сомнениях «резать или нет» — не резать.

Очікування: зараз ми швидко і красиво нашинкуємо моноліт на мікросервіси які можна деплоїти незалежно і кожне з яких виконує одну просту функцію.
Реальність: нам треба щоб сервіси однаково писали логи, репортили телеметрію, зберігали секрети, враховували сценарії в яких їх використовують, передавали дані які не використовують іншим сервісам, знали структуру та семантику повідомлень і так далі.
Через короткий проміжок часу: ми запиляли фрейморк для мікросервісів який все це робить... от тільки тепер всі мікросервіси мають бути написані однією мовою з набором бібліотек певних версій, мають деплоїтися у певному порядку і будь-яка зміна в структурах БД чи повідомлень тепер проходить черес майже усі «мікро»-сервіси.
Коли це все нарешті працює в продакшені: щось якось забагато роботи на кожну функцію робити мікросервіс і знову і знову додавати кроки у деплоймент, моніторинг і таке інше — тому будемо дописувати все нове у більше підходящі вже-не-мікро-сервіси.
Через 5 років: у нас легасі моноліт, з нього 30% виділено у мікро-сервіси-моноліти і ми не можемо легко і швидко застосовувати нові мови/фреймворки/бібліотеки. А тому ми зараз їх швиденько поділемо на мікросервіси!

от тільки тепер всі мікросервіси мають бути написані однією мовою з набором бібліотек певних версій

Попытки плодить зоопарк лично я бы пресекал всё-таки. Напишите 2 монолита на разных языках (если уже прям так надо) — сильно легче станет?)

мають деплоїтися у певному порядку

Почему? В общем случае нет, не должны.

будь-яка зміна в структурах БД чи повідомлень тепер проходить черес майже усі «мікро»-сервіси

БД — нет, конечно. Сообщений: зависит от сообщения и насколько хорошо подумали про версионирование (если плохо подумали, тогда может быть надобность обновить всех подписчиков перед обновлением продюсера).

извините, в 21м году, писать общую инфу про распил монолита на микросервисы это пук в воду, про это пишет каждый второй
ни слова про ассинхронность, ни про data consistency, ни про service mesh и тд

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

якщо Ви запускаєте білд і бачите помилку, і фіксите — це моноліт. Якщо помилку знаходять на проді що неконсистентно оброблюються дані, а вирішення проблеми починається з емейлів — це мікросервіси

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

Оце от п’ять років я учасник коммюніті JHipster і всі ці п’ять років йдуть холівари на рахунок мікросервісів... На сьогодні JHipster позиціонується як готовий солюшн по мікросервісах і є певні моменти, з якими всі сторони холівару погодилися:

1. Якщо проектом займається лише одна команда — має бути моноліт.
2. Якщо від початку планується використовувати мессадж брокери — Kafka, Solace etc — є сенс в мікросервісах навідь коли команда одна.
3. Так чи інакше все має починатися з архітектури.
4. Мікросервіси — це паттерн, який вирішує певні проблеми. Немає проблем — тоді це антіпатерн.

А если в проекте «органично» сочетаются пункты 1 и 2, то пункт 3 определенно пропустили на более ранних этапах как ненужный )

А скинь, будь-ласка, лінку на патерни та антипатерни для мікросервісів. Чи назву книжки, де добре описано.

Вы простите, что вмешиваюсь из недавнего на эту тему неплохо зашло вот это:
www.amazon.com/...​-Richardson/dp/1617294543

Книжка супер! Спасибо! Дочитал только что)

Якщо від початку планується використовувати мессадж брокери — Kafka, Solace etc

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

А ваш аргумент зачастую работает в обратную сторону:
Мы хотим микросервисы ->
между сервисом А и Б нужно передать сообщение ->
STOMP/AMQP/JMS «не модно» ->
осталась кафка ->
ДАА!! КАФКАА!!! ->
а куда ж кафку без микросервисов?! Засмеют! ->
только микросервисы

При этом «мы с командой выбрали кафку» ставится как изначальный аргумент, но на самом деле ее выбрали потому что модно и микросервисно.

А в чем разница между

между сервисом А и Б нужно передать сообщение ->
между микросервисом А и Б нужно передать сообщение ->

?
На мой взгляд разница между распределенными сервисами и распределенными микросервисами чисто в названии и лишь в том, как происходит разбиение с точки зрения бизнес-задач. Всякие сопутствующие паттерны как лучше строить распределенные сервисы вытекают по большому счету из того что у вас есть пучок распределенных сервисов. А уж насколько они «микро» — не столь принципиально.

А в чем разница между

между сервисом А и Б нужно передать сообщение ->

Там имелось в виду [микро]сервис

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

Да, согласен. Просто классическая сервисная архитектура допускает наличие нужного количества условных монолитных сервисов. Что не влечет за собой раздувание инфраструктуры и распыление кода по 146 репозиториям.

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

По сути, «микросервисы» — это карт-бланш архитекторам пуститься во все тяжкие и применять все паттерны до которых можно дотянуться просто потому что они есть.

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

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

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

Если я правильно понимаю что вы имеете в виду под классической сервисной архитектуры — то она предполагала

Нет, совсем не это.
Можно и в клауды и вот это все.

Но без стремления к микросервисности ради нее самой. Без попытки распилить все на атомы джаст бикоз ви кен.

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

Я за то, чтобы система писалась как монолит, пока не станет очевидной необходимость переходить от монолита к СОА как к нескольким монолитам поменьше, а от к СОА к микросервисам, если это будет нужно. А не сразу вкатить в проект кафку и кластеризацию а потом вспомнить, что у нас 2 юзера в час, которые делают инсерт 1 строчки в таблицу из 3 колонок. Зато мы уже успели втянуть кафку!

Условная кафка и кластеризация решает проблемы в аспекте availability и решает некоторые из проблем network communication, а не только скейлинга.
То есть если у нас 2 юзера, но требование 99,999 SLA то без кластеризации и месседж брокера скорее всего не обойтись.

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

Да, попадалось где-то эпичное видео на эту тему, про чуваков в каком-то финтех стартапе лондонском, которые напиляли 1500 микросервисов хер пойми зачем www.youtube.com/watch?v=t7iVCIYQbgk

Условная кафка и кластеризация решает проблемы в аспекте availability

Да, ты прав. Под «кафкой и кластеризацией» я имел ввиду больше все сопутствующие проблемы и оверинжиниринг и овертулинг так сказать.

напиляли 1500 микросервисов

Вово, я про это

Да, попадалось где-то эпичное видео на эту тему, про чуваков в каком-то финтех стартапе лондонском, которые напиляли 1500 микросервисов хер пойми зачем www.youtube.com/watch?v=t7iVCIYQbgk

Monzo. Хороший пойнт — мне это даже приводили как пример. Но если разобраться, как они это делали, то фактически обнаружится, что это самые настоящие функции (дословно не вспомню, но звучала фраза вроде each network rule is a separate microservice, т.е. на каждый эндпойнт у них свой узел)... но ведь 99% микросервисных систем пишутся не так, поэтому в тех же 99% любой пример Монзо летит в корзину).

дословно не вспомню, но звучала фраза вроде each network rule is a separate microservice, т.е. на каждый эндпойнт у них свой узел

Смысл такого подхода для меня все равно не понятен :)

Мне тоже — я бы просто побоялся так писать. Даже если взять CQS, который я практикую, и представить, что каждая команда и кверя будет условно превращена в отдельный деплоймент юнит, то стрёмно не учесть все побочки от такого подхода (я даже не говорю про инфру — банально побочки при разработке).

Может, они решили испытать akka и так это обозвали?

40 человек вместо 5 — мечта.
Hint: еще можно каждый сервис на новом языке писать, тогда еще круче будет

40 это кстати средненькая команда. Когда всего 40 ещё все относительно хорошо. Вот 200-500 причем ещё с разных стран и континентов вот тут все прелести. Особенно с калейдоскопом технологий и несогласованной или вообще без документации.

еще можно каждый сервис на новом языке писать, тогда еще круче будет

Вы к слову зря иронизируете. Это между прочим реальный кейс. И все отлично работает.
причин несколько:

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

— бизнесу надо сделать ну очень быстро, а нужных вам людей нет.
к примеру у вас стек сервисов на Ruby + Go, а вам закинули ребят, которые на ноде мастера.

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

P.S.
Сугубо личное мнение — проект надо написать с монолита, а потом он должен органически распадаться

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

Микросервисы раньше называлися интерфейсами и все ок работало. А еще до этого — ком обьектами. А до того — сетевым взаимодействием и udp сетью. Хороший инструмент, но везде его пихать как сейчас модно безсмысленно совершенно.

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

В общем-то ничего нового. Микросервисы это логическое продолжение распределенных архитектур реализованных цать лет назад с помощью COM, CORBA и RPC

логическое продолжение распределенных архитектур реализованных цать лет назад с помощью COM

actually DCOM ))

ЗЫ: и нет я не думаю что микросервисы это продолжение DCOM но вопрос интересный

а EJB «продолжение» COM+ в некотором роде. поддержка распределенных транзакций внешним транзакшн менеджером — уже было. все в этом мире баян :-))

а вот COM+ таки да очень уже похож только все вопросы RPC заранее решены на уровне идеологии ))

ЗЫ: причём ведь ещё и позволяет это делать на разных языках

В нас навіть був комерційний проект, де була CORBA...

О часи, о Даніє нещасна!

у меня проект был C++ на Solaris , CORBA и миграция сего чуда с Solaris на Linux

Під солярою я вперше пробував вийти з vim. Традиційно...

Я нещодавно її бачив як «бажано знати modern technologies» в котрійсь вакансії. Може, автомотів — не пам’ятаю.

а вам закинули ребят, которые на ноде мастера.

А завтра обратно забрали, а у вас в комманде условной ноды никто не знает, и про те сервисы тоже без дупля, потому что документации нет :)

потому что документации нет

У кого нет, тому нечего делать в микросервисах. Если Н не делает документацию — это не проблема концепции, это проблемы того, кто не делает так, как необходимо.
проведу аналогию — если Вы не пристегнулись в машине и подушки безопасности сломали вам шею, то это не повод говорить, что подушки это плохо и машины плохо.

я и не говорю про плохо, я говорю про реалии. Особенно всяких стартапов как у автора — где текучесть людей большая, уровень и дисциплина рабочих процессов низкая.

к примеру человек хочет попробовать что-то написать на новом инструменте. Очень хорошо заходит.

пусть пишет в свободное от работы время

Это очень часто встречается. Например функционал связанный с машин лернингом или математическими формулами легче реализовать на Пайтоне а всякие легаси ентерпрайз проекты часто написаны на Java или C#. Бывает смесь того и другого тк каждая команда исторически пишет на чем умеет. Вот и дергаем пайтон сервис из джавы и сишарпа

В нас колись на одному проекті були С++, C# і Python. І ми робили між ними interop. Бо треба було.

І для цього всього були цілком конкретні ділові підстави.

MVP запустили за півтора місяці. Правда, я після того ще півтора місяця валався з грипом. Але запустилися за день до дедлайну.

Переход к микросервисам — это не только изменение архитектуры кода, но и самой команды. [...] Когда-то нас было пятеро, сейчас около 40 человек

Для аутсорса — самое оно =)

Поделят на «стримы просто» — команды по 5-7 человек каждая возьмёт себе конкретный кусок. Синиоры будут бегать по митингам днями согласовывая между собой всякие моменты. Остальные будут работать так же как и в маленькой команде. Монолит большими командами пилят так-же но с организацией вообще происходит коллапс, вплоть до очереди на комит которой ждешь неделю, вечно красным радиатором, драками в код ревью и т.д.

а всего то достаточно распилить монолит на кучки согласованные интерфейсами и между кучками только согласованные интерфейсы а стоп это же ж уже почти микросервисы ))

но без скрытых расходов на :
— Изменение подхода к работе с мастер-данными
— Написание кода по-новому, невозможность переиспользования исходного кода монолита
— Проектирование IT-продукта заново
— Создание новой инфраструктуры
— Измерение и проверка SLA
— Вклад в fault tolerance на всех уровнях
— Реорганизация команд
— Работы по обратной совместимости (Бизнесу захочется снизить свои риски и не выключать монолит сразу, а переходить на микросервисы постепенно)
— Интеграция служб поддержки (Микросервисы добавят на порядок больше точек отказа, ... вы получаете рост точек интеграции, усложнение процесса CI/CD и распределение мастер-данных, что значительно усложнит всю инфраструктуру)
— Догоняющий поток фич (Пока новая система постепенно заменяет старую, бизнес не стоит на месте. Не получится поставить на паузу поток новых фич)
(хабр Скрытые расходы при переходе на микросервисы)

а как почитаешь, взяли да и распилили монолит, «делов то!».
это ж куда проще чем задокументировать и отрефакторить монолит, верно?

Это принцип проектирования, ему обучают как раз на курсах экскаваторщиков :)

Я колись на цю тему навіть стартап починав... Але не пішло.

Практика показывает что микросервисную архитектуру нужно проектировать аналогично монолиту. Ее сложно поддерживать и она имеет выгоды только для крупных проектов, впрочем существенные. Все сервисы должны быть согласованы между собой, все API документированы и т.д. Обязательно должны создаваться и сопровождаться все архитектурные документы. Если все происходит по принципу — «каждый делает что хочет» в итоге имеем системы где сообщение от одного сервиса к другому идёт через 11 узлов, и естественно не доходит. И в течении трёх месяцев на прод не заходит нужная функциональность, но даже после того как заходит — на проде она ещё и падает. Потом вызывают — архитектора и менеджмент его принудительно заставляет нарисовать архитектуру по тому хаосу что есть.

Все сервисы должны быть согласованы между собой, все API документированы и т.д. Обязательно должны создаваться и сопровождаться все архитектурные документы.

а если все это будет сделано для модулей, плагинов, компонент, слоев монолита?

то есть, когда говорят о том как делать микросервисную систему мне часто вспоминаются сказки
Каша из топора
Суп из булыжников

Я так и написал что нет разницы, в обоих случаях это надо делать архитектуру а не сразу коддировать. Однако в случае микро-сервисного подхода этому нужно уделить ещё больше времени (и соответственно времени дорогих специалистов). SOA подход известен давно. Его основные преимущества — можно использовать разное оборудование для нагруженных и не нагруженных компонентов, если такового используется много (например больше 50 северов) это позволяет экономить существенные средства в эксплуатации. Сопроводждать и обновлять одни части системы относительно независимо от других — например чаще абгредить UI не трогая бизнес логику. Но за это придется заплатить сложным DevOps, четкой документацией и архитектурой, специальными мерами по поддержке согласованности данных. Для не больших и средних систем это невыгодно, для больших и высоко-нагруженых напротив. Если действовать по принципу Amazon 5 — это микросервисы и у нас будут на сайте доставки пиццы то тут ...

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

а системы то в основном небольшие и средние :)

например больше 50 северов

например хиленький такой проект:
This is with just 25 servers. For everything.

2014, StackOverflow Update: 560M Pageviews a Month, 25 Servers, and It’s All About Performance
и
stackexchange.com/performance

Ну у меня нет такой статистики. Лично я с 2010-го года работаю только со средними и большими с высокой нагрузкой на них. Для больших и сложных eCommerce систем выгода однозначная в том числе и финансовая. Когда количество серверов в кластере переваливает за сотню уже выгодно оптимизировать софт. Положим есть у нас монолит который в себе содержит все и от того потребляет 12 ГБ ОЗУ, но пропускная способность одного нода оказываться крайне низкой до 100-ни одновременно работающих пользователей. В итоге чтобы «не упасть» в в черную пятницу или кибр понедельник — нужно будет поднять до 200-т серверов причем дорогих. eCommerce делают в эти два дня до 80% выручки за год и поэтому падать нельзя. После профилирования оказывается что самый высоко-нагруженный компонент системы UI — RIA с кучей AJAX и прочих финтифлюшек (stackoverflow такой не нужен). Бизнес считает этот компонент самым важным для них т.к. Usability заставляет покупать online, а не идти в магазин или на сайт конкурентов. Тут постоянно происходят всякие переработки и обновления, никто не хочет ждать 3-ри месяца релизного цикла монолита чтобы получить новый UI к checkout flow. На поверку это все можно сделать через толстый клиент через Angular/Ract/Vue и т.п. и бекенд вынести в отдельный сервис, ему еже не нужно все 12-гб и соответственно можно использовать сервера по дешевле, заодно можно разнести CMS данные и бизнес логику по разным BD. Притом для CMS лучше подходит No SQL решения, тогда как для бизнес логики напротив реляционные базы данных. Потом строятся сервисы с базовой и дополнительной бизнес логикой и т.п. Да кластер сильно усложняется, но каждый его составной компонент напротив упрощается. Система проще масштабируется, держит высокую нагрузку и т.п. Я не топлю за микросервисную SOA как единственно правильный подход, в месте с тем в ряде случаев он имеет свои преимущества.

Ну у меня нет такой статистики.

она есть, кругом. просто вы закрываете глаза на нее :)

Для больших и сложных eCommerce систем выгода однозначная в том числе и финансовая. Когда количество серверов в кластере переваливает за сотню уже выгодно оптимизировать софт

и какой процент eCommerce решений с таким размером бизнеса?, ну так, с потолка?

Я не топлю за микросервисную SOA как единственно правильный подход, в месте с тем в ряде случаев он имеет свои преимущества.

в ряде случаев — все имеет свои преимущества.
в ряде случаев наверное все и на Rust нужно переписать, и свои датацентры развернуть. Причем вложившись в разработку собственного железа, и заказать у TSMC
длина этого ряда напримере в количестве задейсвтованных программистов в таких проектах какая в сравнении в «WP+Woocommerce»? ну или ладно, даже Magento

я не хейтю микросервисы. просто в них часто видят панацею от бардака что творится в разработке.
И часто-густо их выбирают не по техническим причинам: «когда количество серверов в кластере переваливает за сотню» — а вследствие закона Конвея — не можем менеджить команды, ну так пусть каждая в своей песочнице ковыряется, и как-то там, потом сконектим то что наковыряли.

по крайней мере так обычно описывают — не смогли сработать команды, вот и выбрали микросервисы, а не
у нас уже и 200 дедик серверов не справлялись, и памяти в них напихали под завязку, — вот и приняли решение, пора пилить наши монолиты на микросервисы

Да кластер сильно усложняется, но каждый его составной компонент напротив упрощается

а с модулями монолита этого нельзя значит было сделать :)
в архитектуру в монолите — невозможно?

и про
Да кластер сильно усложняется
естественно в том и неявняая ложь адептов микросервисов, и воздыхания о серебрянной пуле
потому что

нельзя сделать систему проще чем задача. сложнее — можно, а проще — нельзя.
значит если какая-то часть системы упрощается — то сложность перетекает в другую ее часть

я не хейтю микросервисы. просто в них часто видят панацею от бардака что творится в разработке

ну тут мы солидарны, решать проблему бардака (неэффективного менеджмента) микро-сервисами — это тоже что тушить пожар бензином.

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

а домен — всегда эволюционирует, у бизнеса фантазия неуемная.
И ТЗ — всегда изменится. И скоуп — всегда будет изменен.
Бортовое ПО, у программистов NASA может и стабилен, не знаю точно, далек.

К задаче можно подходить

о каком этапе речь, анализе, проектировании функционала, выбор архиктерных принципов, решений по дизайну, инженерной декомпозиции, ..., ..., распилу на таски для «джунов»?

тут же вопрос проще
какие причины, критерии для принятия решения — распиливаем монолит на микросервисы!

и я тролю вот такие
«команда в десятки человек — не можем менеджить, ни команду, ни проектную документацию. переложим все эти сложности на девопс!» (как Фелини всерьез шутил — фильмы делаю не я, а мой монтажер. я просто снимаю дубли и варианты)
«крудошлепы — нубы, не в состоянии осилить азбуку работы с уровнями изоляций и блокировками в рсубд»
«у нас хайлоад! потому что сотня одновременно работающих пользователей кладет сайт!»

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

То есть, если divide & conquer сработал — то на какое-то время сложность не перетекает, а можно работать с одним уровнем одного куска.

интересное предложение. потому что ничего не понял :)
divide & conquer — это что?
сработал — это как, что значит — сработал в отличие от не сработал?
какое-то время сложность не перетекает — она есть свойство самой задачи
а можно работать с одним уровнем — чего?
одного куска — чего?

а «нельзя сделать систему проще чем задача» — это ж не мое :)
это ж перифраз начиная с гносеологии, и заканчивая критикой Торвальдсом идей микроядра.

divide & conquer — это что?

Разделение на слои и модули. Разрабатываем двигатель отдельно, колесо — отдельно.

сработал — это как, что значит — сработал в отличие от не сработал?

Это значит — хорошо описывает домен (прога покрывает потребности пользователей) и результат достаточно гибкий, чтобы относительно легко приспосабливаться к последующим изменениям требований (уточнению домена).

какое-то время сложность не перетекает

Домен был кластеризован относительно правильно, и нет нужды переносить функциональность между сабдоменами.

а можно работать с одним уровнем

Один слой одного модуля. Layers/Actors/Microkernel/Blackboard/etc. Конкретные задача не приводят к сильному увеличению связности компоненов, несущих бизнес-логику.

критикой Торвальдсом идей микроядра.

Торвальдс может критиковать микроядро в ОС. Тем не менее, существует QNX, и всякие корбы работают по принципу микроядра (если иметь в виду паттерн из POSA1, а не операционную систему). Думаю, тот же Эклипс IDE тоже недалеко ушел, судя по конфигурабельности.
www.researchgate.net/...​e-overview_fig1_224101700

Разрабатываем двигатель отдельно, колесо — отдельно.

разрабатывать можно и отдельно
а изготавливать можно и литьем сплошного изделия.

я к тому что тут та же история
проектирование и изготовление — разные процессы.

Это значит — хорошо описывает домен

то есть речь об этапе анализа

прога покрывает потребности пользователей

ыть, а прога к нему при чем — к описанию домена?

этим — описанием домена и изготовлением проги даже разные люди нередко занимаются, и сидят в разных офисах

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

результат — описание домена ИЛИ прога?
это разные совсем результаты.
и их гибкость — независима друг от друга

Домен был кластеризован относительно правильно, и нет нужды переносить функциональность между сабдоменами.

каковы критерии оценки — правильности анализа, то есть кластеризации домена, и проведения границ между сабдоменами?

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

Абстракции текут. Если еще не потекли — готовтесь. причем потекут не в тех местах где вы предполагаете :)

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

Торвальдс может критиковать микроядро в ОС.

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

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

Тем не менее, существует QNX

конечно существует. как и Linux — существует.
как и монолиты существуют, и микросервисные системы — тоже существуют.

речь не о том что нечто не может существовать :)

Думаю, тот же Эклипс IDE тоже недалеко ушел, судя по конфигурабельности.

Так и Wordpress и Magento — очень конфигурабельны.
Wordpress`у эта гибкость и обеспечила мегапопулярность.

конфигурабельность можно обеспечить многими способами.
даже без «анализа домена»

проектирование и изготовление — разные процессы.

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

то есть речь об этапе анализа

 См. выше

ыть, а прога к нему при чем — к описанию домена?

этим — описанием домена и изготовлением проги даже разные люди нередко занимаются, и сидят в разных офисах

 А потом, когда изменились требования — фиг их заимплементишь, потому что прога непонятно как работает, и ее структура нормально не мапится на модель домена (если последняя вообще есть)

результат — описание домена ИЛИ прога?
это разные совсем результаты.
и их гибкость — независима друг от друга

 См. выше и книжки по DDD.

каковы критерии оценки — правильности анализа, то есть кластеризации домена, и проведения границ между сабдоменами?

Легкость внесения непредвиденных изменений (требований) в код.

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

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

Как раз то, из-за чего появилось DDD.

DDD, как по мне, базируется на идее что между теорией и практикой нет разницы. что программный код — это переписанная на формальном языке спецификация и результаты анализа домена

и это действительно отчасти так, чем ближе описанное в коде к описанному в спеке, тем лучше.

А потом, когда изменились требования — фиг их заимплементишь, потому что прога непонятно как работает

ничего, как-то имплементят :) на практике. и чем дальше, тем все дальше от той красотени что была в теории.

например бац, вот ё, надо учесть границы транзакций у персистентного хранилища. вот ё, дедлок!
а в описании домена ничего такого не было :(

См. выше и книжки по DDD.

смотрел, читал, холиварил много где, последние лет 5.
а недавно вспомнил статью про rich vs anemic, где комменты оставил. 2012ый год однако был.

Легкость внесения непредвиденных изменений (требований) в код.

это зависит от — кода.
и обычно чем академичней ОО код — тем тяжелее вносить в него изменения. на практике уже столько шишек набито, что аж стало всем известным
«Избегайте наследования в пользу композиции!»

И для него программисты должны понимать и домен

понимание домена не обязано приводить к DDD
а то и наоборот — понимание домена может приводить к осознанному отказу от DDD и прочих подобных канонических подходов.

иначе либо прога перестанет соответствовать модели домена

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

либо архитектура станет слишком жесткой и неизменяемой.

вот потому я и сторонник anemic. потому что rich лежащая в основе DDD — более жесткая и неизменяемая.
на доу было несколько холиваров об этом, в которых участвовал

например бац, вот ё, надо учесть границы транзакций у персистентного хранилища. вот ё, дедлок!
а в описании домена ничего такого не было :(

А пары по гексагональной архитектуре прогуляли? Чтобы от БД энкапсулироваться.

у меня не было таких пар вообще.
как и по ООП.

а от БД энкапсулироваться — с какой целью?
какую задачу решаем?

ORMы вона, «энкапсулируют»
да так, что как не так давно у соседей
пришло под 100 пользователей и сервер колом встал
глянул я на запросы, и только стейкхолдеру сказал
«меня к ним не подпускать — пристрелю, не сдержусь»

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

Какие главные проблемы призвана решить архитектура X?
это и есть вопрос, с ответа на который нужно начинать.

а у меня энтерпрайз, у меня БД «неотъемлимая» часть системы. Без нее — вся система никому не нужна вообще и никак.
Как для пользователей, так и для аналитиков — все ценное там, в БД, а не в приложении.

у меня не было таких пар вообще.
как и по ООП.

У меня тоже

а от БД энкапсулироваться — с какой целью?
какую задачу решаем?

Все сразу.
1) Защита от vendor/version lock-in
2) Возможность работы и тестирования с заглушками
3) Запись/воспроизведение событий
4) Можно базу сделать однопоточной для скорости работы
5) Можно кешировать содержимое базы как вздумается

От вендора — чего?
Тестирование организовывается чего угодно, хоть сплошных ХП.
Событий каких,чего. Что за события,какой их доменный смысл,и что нам от них нужно.
Однопоточная база — для работы в многопоточном измении данных — которые отражают ограниченность ресурса — для быстродействия? Это как?
Кеширование — а инвалидация не нужна? Как закешировать текущие остатки?

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

А вы о каком домене?

От вендора — чего?

От вендора базы данных.

Тестирование организовывается чего угодно, хоть сплошных ХП.
Событий каких,чего. Что за события,какой их доменный смысл,и что нам от них нужно.

Всех внешних событий. Если произошел глюк или креш — можно сделать event replay и отдебажить проблему, которая прошлой ночью уронила прод. Reproducible bug == dead bug.
ithare.com/...​-systems-with-transcript

Однопоточная база — для работы в многопоточном измении данных — которые отражают ограниченность ресурса — для быстродействия? Это как?
Кеширование — а инвалидация не нужна? Как закешировать текущие остатки?

Write-through или любой другой тип кеша, или свой тип под каждый тип данных. Вот по скорости
ithare.com/...​hreading-with-a-script/3

А, от вендора БД. Да, слышал такую байку, что раз -и сменил БД :)
Бывает конечно, меняют. Как раз начал смотреть доклад где рассказывается как попытались, вложились, и зафейлились.

Примерно как монолит распиливают. Откуда только стон о легаси системах... Распилить да и все.

Глюк или креш обычно отслеживается системами мониторинга и логирования. Я не называю это событием.

По ссылке какая-то низкоуровневая статья. И с гиганскими цифрами. Далекая от меня, я в проектах для таких крупных бизнесов не участвовал и не предвидится. У топовых бизнесов всегда свои, уникальные потребности и методы которые для простых смертных — из пушки по воробьям.
Да и средства кеширования не изобретаю, а использую те что есть.
Но важнее — проектировать сразу без грубых ошибок «абстрагирования от БД»

Но важнее — проектировать сразу без грубых ошибок „абстрагирования от БД”

То есть:

Hexagonal architecture alistair.cockburn.us/hexagonal-architecture
Create your application to work without either a UI or a database so you can run automated regression-tests against the application, work when the database becomes unavailable, and link applications together without any user involvement.

Clean Architecture blog.cleancoder.com/...​e-clean-architecture.html
Independent of Database. You can swap out Oracle or SQL Server, for Mongo, BigTable, CouchDB, or something else. Your business rules are not bound to the database.

и прочие луковицы уже можно считать ошибками?

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

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

Адаптер как раз чтобы не лишиться плюшек

Плюшки у каждого типа БД — уникальны.

А значит интерфейс должен описать — все виды плюшек, всех типов БД.

у меня вот фантазии не хватает, как будет выглядеть интерфейс для «SQL» и MUMPS например.
если же заставить работать SQL как MUMPS — то это ж 314ец ему, SQ.
если MUMPS как SQL — то тоже 314ец, и главное — нафик он тогда нужен.
MUMPS вспомнился потому что я к нему легаси драйвер на Джаве переписывал, и вышло что почти весь сам и написал.
поставьте любую NoSQL БД вместо него.

Но да, это для проектов, которые

используют любую базу одинаково — как key-value storage

либо — сам интерфейс только будет супер заумь, «для всего на свете что есть, и что может появиться» через

несколько лет

не говоря об имплементации для конкретной приличной БД.

Плюшки у каждого типа БД — уникальны.
А значит интерфейс должен описать — все виды плюшек, всех типов БД.

Нет, интерфейс позволяет сохранять, находить и восстанавливать доменные объекты. И под капотом может использовать плюшки, если получится.

если же заставить работать SQL как MUMPS — то это ж 314ец ему, SQ.
если MUMPS как SQL — то тоже 314ец, и главное — нафик он тогда нужен.

Но один и тот же домен в разных имплементациях могут хранить или в одном, или в другом — правильно? Кому как понравится и как удобнее. Вот делаем возможность хранения данных, не раскрывая, где они хранятся. Encapsulation, dependency inversion, interfaces, модульность и прочие умные слова.

либо — сам интерфейс только будет супер заумь, «для всего на свете что есть, и что может появиться» через

Нет, интерфейс дает методы: создать товар, удалить товар, найти товары по алфавиту, увеличить или уменьшить количество товаров на полке.

Нет, интерфейс позволяет сохранять, находить и восстанавливать доменные объекты.

по каким условиям?

И под капотом может использовать плюшки, если получится.

мне надо эти плюшки от БД. я знаю что они у нее есть.
либо писать их самостоятельно. много кода — много ошибок.

но интрефейс от меня спрятал эти плюшки.
что я сделаю? что и большинство — «поблагодарю х-ями» архитектора, и влезу вместо интерфейса.

уже просто потому что таску с помощью плюшек я буду закрывать 3 часа. а без — 3 дня. и тех лид — одобрит. потому что ему поставили срок — 2 дня на все, и на меня в частности.

Нет, интерфейс дает методы: создать товар, удалить товар, найти товары по алфавиту, увеличить или уменьшить количество товаров на полке.

и все? а товары купленные конкретным юзером — уже нельзя?
а товары купленные конкретным юзером, но возвращенные в «14 дней» имею ли я право получить?

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

а что с характеристиками товаров?
ну там типом, цветом, весом, материалом, ...., ...,

тоже все сам выгребай и своим кодом сопотавляй?

по каким условиям?

По каким нужно будет — по таким можно написать. Сомневаюсь, что нужен поиск пользователя по имени. А вот по имени и фамилии — может быть.

и все? а товары купленные конкретным юзером — уже нельзя?
а товары купленные конкретным юзером, но возвращенные в «14 дней» имею ли я право получить?

Если это сохраняется в базе — можно через поля в спецификации для поискового запроса. Спецификация — plain old data с набором возможных параметров для сравнения или поиска.

а домен — всегда эволюционирует, у бизнеса фантазия неуемная.

Эволюция гораздо проще в монолите, где весь домен в одном месте.
А не в микросервисах, где либа какихто markup language схем для кодогенерации — в 5 репозиториях, классы дописываются еще в 9, а все это используется и еще раз дописывается в каждом микросервисе вообще. В результат даже просто выяснить всю цепочку наследования типа и посмотреть его код превращается в нетривиальную задачу и требует обращаться к какому-то местному бородатому гуру, который на проекте 3 года и помнит наизусть все зависимости, но занят на митингах, поэтому не отвечает на вопросы еще три дня.

Так это ни разу не микросервисы, а обычная слоистая архитектура.
У микросервисов каждый сервис берет свой кусок домена (разделение по вертикальным границам).

Не понимаю реплики ? Если вы про одноранговые связи между модулями — то это признак хорошего дизайна для любой системы, как монолитной так и сервисной. Или кто то взялся стандартизировать подход и дал единое определение микросервисов ? Например — прописал протоколы сообщений, стандартизировал контейниризацию и т.д. ? Если у меня например Terraform eсть — а Kubernetis нет, и сервисы общаются между собой по: ASN1, SOAP и REST в которых не JSON — а XML — это микро сервисная архитектура или нет ???

Насколько я понимаю, отличие микросервисов от SOA в том, что у микросервисов каждый сервис содержит кусок торта по вертикали — у него своя база данных, свой бекенд, и даже может быть свой компонент UI.

В SOA тирамису — куски data layer не связаны однозначно с кусками бекенда, то есть — распределенная слоистая структура между уровнем данных, служебными сервисами, доменными сервисами, и сервисами приложения.

www.tiempodev.com/...​log/microservices-vs-soa

Можете предложить свое определение различия, если это не нравится. Можете даже линк из интернета вынуть в подтверждение.

Хорошая статья кстати, схема с «сравнением» хорошая и правая компоновка. Но мое мнение микросервисы просто вариант компомпоновки SOA не более того. В колличество баз данных и т.п. вообще зависит от конкретного случая. Кстати есть варианты когда вообще нет базы данных, только файлы на S3 лежат. Можем посмотреть скажем Википедию и там увидим — «нет четкого определения». Впрочем нет четкого определения что считать монолитом, скажем база данных у нас на выделенном сервере — уже не монолит? Допустим встроенная бд типа: paradox, sqllight, hsqldb — монолит ? Мое мнение — presentation, buiseness logic и persistence уровни абстракции в одном приложении — монолит, все уровни перемешаны между собой — спагетти код (говнокодише), модульная структура с четкими API — лазанья код. Остальное SOA, Вариант компоновки SOA где каждая подсистема бизнес логики: например платежная система, поддержка каталога, генерация отчетов и т.п. вынесена в отдельное приложение — микросервисная архитектура. Одна там база — 10 или ее вообще нет, уже не принципиально.

Как я понял, n-tier это горизонтальная нарезка, микросервисы — это вертикальные столбики, а SOA — это много кубиков. Сейчас вот почитываю умные книжки (DDD только закончил) чтобы в голове оно все сложилось в систему. Поэтому и лезу не в свою область — проверить, правильно ли понял, и насколько теория соответствует практике.

потребляет 12 ГБ ОЗУ

Это типа очень много? :)

Да. Но и не только в этом проблема по CPU тоже придел есть и по диску. Экономика простая AWS инстансы с 16+ гб памяти — сразу начинают съедать прибыль.

Да, я забыл, что деплой не в авс невозможен. Не хайпово ж. Скоро для хелловорлда придется покупать инстанc жвм у авс.
И public static void main через хелм.

модулей, плагинов, компонент, слоев монолита?

А каждое слово здесь можно распилить еще на 2-3 репозитория. А если пилить синьорно — на 5-6. А потом гордо восседать на куче из 186 репозиториев, которые на самом деле отвечают на запрос SELECT * FROM table WHERE user = ’johndoe’.

А каждое слово здесь можно распилить еще на 2-3 репозитория. А если пилить синьорно — на 5-6.

можно :)
а можно и не распиливать. никто ж не принуждает — решайте сами, как вы храните исходный код modular app, модули которого делаются разными командами, и согласование спецификаций, внутренних API производится на уровне не ниже тех лидов, а не в чатике, коллеге с другой команды — «Петя, а добавь публичный метод, чтобы он делал то-то, а отвечал так-то»

так же как вполне работающие практики бранчевания — развесистый git flow и «есть только master, пушим только в него! а все что не — пул реквесты»
какая из них — противоречащих другу другу — правильная?
а это от команды и процессов разработки зависит :)

А потом гордо восседать на куче из 186 репозиториев

вот монорепозиторий для микросервисной компоновки — слабо представляю зачем нужен :)

никто ж не принуждает

Принуждает то, что условный архитектор начитался какогнибудь микросервисного евангелиста и хочет для селект * фром тейбл хранить жсон запроса-ответа в одном репозитории, сиквель — в другом, урл ендпойнта — в третьем, код объектов — в четвертом, маппинг жсона на объект — в пятом, конфиг веб мвц в шестом, код эндпойнта — в седьмом, конфиг персистентности — в восьмом, а конфиги базы — в девятом.

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

Вот в этом определении архитектуры...
*Архитектура* — это набор формальных и неформальных *правил*, руководствуясь которыми люди проектируют систему.

...самое важное — это явный акцент на том, что суть архитектуры в правилах для людей. Предмет архитектуры, как таковой — не технологии, а люди, которые их делают, и именно они стоят в центре.

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

Именно так, и никак иначе. Не придумывать как делать систему под конкретные требования. А давать людям методику (набор правил), руководствуясь которым конкретные эти люди (а не какие-то там абстрактные) смогут проектировать эффективнее.
...
... Дай я скажу, — спокойно говорит Тол, — Я старше тебя, и наблюдал за свою жизнь много «архитекторов» и «дизайнеров», которые не пишут код. Влад, они очень быстро становятся очень полохими архитекторами и дизайнерами. Год или два — и все.
— Правда?
— Точно. Они довольно быстро теряют связь с реальностью. Когда ты не пишешь код, ты не получаешь обратной связи, ты не видишь, во что выливаются на практике твои мысли. Когда ты не правишь багов, и не сидишь на поддержке, ты лишаешь себя важнейшего элемента обратной связи — ты не видишь, какие решения оказались плохи, а какие хороши. А обратная связь — это сама суть инженерии. Ты ведь уже заметил, что наша база данных по дефектам содержит значительную часть требований? Это жизнь. Так всегда происходит.
(конец цитаты, ЖЖ gaperton)

в итоге, из своего многолетнего опыта, вплоть до того что — с «тру архитекторами» живущими где-то там, в горних высях, вообще нет смысла что-то обсуждать.
их надо воспринимать как стихийное бедствие.
Может в фаангах по другому, или бизнесах из топ-500 списка форбс, не знаю, не бывал в таких.

примерно как поступают часто с скрам-мастерами и т.п. :)
уже потому что как скрам-мастер не несет никакой ответственности, так и архитектор не несет ответственности за сорванный дедлайн, потому что конкретная команда не успела в эту тру архитектуру добавить фичу. и 314тить будут тимлида, техлида и команду (возможно еще и пиэма), а не этого «тру архитектора» который наастронавтил.
такая же история с веб дизайнерами которые ни в зуб ногой в веб верстке — верстальщики и фронтенд девы знают — как тяжело реализовать идеи оторванные от реалий технологии и производства.

когда я сталкиваюсь с архитекторами, у меня первая ж оценка
а этот архитект случайно не филин с анекдота:
— А вы станьте ежиками. У ежиков иголки, их никто не обижает.
— Как же мы станем ежиками?
— Ребята, вы меня ерундой не грузите. Я стратегией занимаюсь.

ну и если это филин очередной (который сродни «эффективному менеджеру») то тогда
«Ясно. Понятно»
и дальше по обстоятельствам, политической ситуации на проекте.

Ты все правильно написал, но...

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

В реальной жизни архитекторы именно это и делают. Потому что бизнес не платит за продумывание работы людей правил бла бла бла, а чтобы система Х делала то-то и то-то за такое-то время. А, еще мы хотим чтобы все было на графкл, амазоне и %other_buzzwords_list%.

в итоге, из своего многолетнего опыта, вплоть до того что — с «тру архитекторами» живущими где-то там, в горних высях, вообще нет смысла что-то обсуждать.

Обсуждать нет смысла. Но он уже твой начальник :)

Если в целом, то именно таких архитекторов я и встречал.

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

Но он уже твой начальник :)

У архитектов редко бывают подчинённые.

Да и как «пересидеть начальника» вариантов много.

Поэтому и важно выявить тип архитекта на ранних этапах. Чтобы выбрать адекватную линию поведения

knowledge-sharing architect

Архитектор несет непосредственную личную ответственность не «за систему», а за продуктивность всех членов команды в их повседневной работе.
Его обязанность — усиливать людей, снабжая их необходимыми технологиями для выполнения повседневных задач по проектированию системы.

способы усиления описаны:
code reviews
pair programming
considering architecture-change
and discussions with team members

чтобы от него была польза

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

Microservices promise a scalable architecture, increased flexibility, and better performance. But then you find out what’s actually involved in designing, developing, and running a microservices-based architecture. It turns out it’s not that straightforward after all.

Often the discussion around microservices is framed by a false dichotomy between the messy monolith and the lean and mean microservices architecture. Sander Mak explains that there’s a third way: the modularized application. Functional decomposition of your application doesn’t imply that every component has to become its own independent process.
www.slideshare.net/...​/modules-or-microservices

Что-то попахивает рекламой
1) Он ушел в поддержку модулей в языке, которая по сути — синтаксический сахар.
2) Если брать DDD (enterprise-scale solutions), там упоминается проблема поддержки общего контекста между командами. Когда на проекте работают 100 человек — тяжело сделать для всех удобный интерфейс, неограничивающую функциональность, и не попутать контракты. Так как микросервисы (в теории) более независимы, чем модули, то и интерфейсы у них уже и лучше специфицированы.
3) Линукс ну никак не один процесс, о котором он говорит. Или там имелось в виду ядро? Так в ядре вендоры работают независимо, каждый над поддержкой своего железа.
4) На большом проекте синхронные вызовы в чужой код — зло. Ты не знаешь, на чем вызов тормознет, и где задедлочится.
5) То же самое с масштабируемостью по ресурсам — когда 10 микросервисов будут жить каждый на своей машине, монолит на своей уже может захлебнуться по процу или памяти.

Думаю (возможно, не прав — нет опыта с распределенными системами), проблема проектов, стартующих с микросервисов, в недостаточно зрелой доменной модели. Когда обнаруживается, что разбили неверно, и кусок функционала нужно перетащить из одного микросервиса в другой — это слишком дорого. Также несколько сервисов могут стать сильно связанными — тогда либо в тормоза с RPC, либо в дупликацию и несогласованность данных (и нагрузку на проц и сеть).

Вероятно, поэтому Фаулер рекомендует начинать с монолита, а потом постепенно переходить к микросервисам (если доживешь) martinfowler.com/bliki/MonolithFirst.html

То же самое с масштабируемостью по ресурсам — когда 10 микросервисов будут жить каждый на своей машине, монолит на своей уже может захлебнуться по процу или памяти.

Так никто ж не запрещает развернуть application level монолита (если он, конечно, stateless) тоже на куче нод. А там балансируй хоть round robin’ом на все, либо по роутам/поддоменам каждый модуль на свою группу серверов.

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

Не все можно в stateless. Как минимум — нагрузка проца из-за сериализации и нагрузка на базу будет. Как максимум — может вообще быть непонятно, как расшардить базу.
Хотя, у меня в этом практики нет — домен сильно отличается.

Конечно нет универсального решения, но state-данные по производительности лучше не в базу, а в отдельное in memory хранилище ложится. Да, latency больше по сравнению с локальной памятью, но и при цепочке вызовов микросервисов она растёт.
А вот масштабирование persistent слоя, это отдельный большой вопрос, который в микросервисах тоже никуда не исчезает.

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

1) его способ — не обязателен. главное что монолит не обязан быть переплетением протекших абстракций.
2) DDD — ни при чем.

Когда на проекте работают 100 человек — тяжело сделать для всех удобный интерфейс

а не надо всем 100+ удобный интерфейс ко всем модулям. Слоить надо. Я вот не знаю какой интерфейс у компонент Линукса/Винды.
3) Линукс ругали многие, как «монолит», сейчас уже забылось. Думаю он поэтому использовал его как пример.
4) другой способ — плагины. проблемы и с ними бывают, но куда меньшие чем с микросервисами
5) там есть картинка о масштабируемости, с которой нет проблем у 80% проектов

проблема проектов, стартующих с микросервисов

а вот тут как раз нет — если проект с нуля микросервисный, то все может быть и ок.
Особенно в случаях когда на этапе MVP проект был простой, и была проблема только с масштабируемостью — стартап демонстрирующий решение работающее с «миллионами IoT устройств»

Вот техническая статья, соответствующая заголовку
www.hillside.net/...​lop/2020/papers/yoder.pdf

Судя по описанным проблемам косвенно можно сделать вывод, что проблема была не в монолите, а его плохой архитектуре — сложность изменений и поддержки, тяжело вьехать новичкам в большой проект, сильная взаимосвязанность компонентов — «поменяли одно, сломалось другое».
Ничего из этого не является необходимой причиной для перехода на микросервисы.
По большому счету я увидел только 2 причины почему перешли на микросервисы:

взаимодействие PHP и Golang.
за окном 2020 год, а на мониторе в коде 2003-й ... Чем разнообразнее база знаний, тем специалист ценнее на рынке

перевел как раз микросервисы в монолит.
появилась констистентность, версионность, единая транзакционная миграция данных, меньше конфигов, меньше ресурсов, единый api
та....

Похоже на новый тренд

тренду уже пара лет:
The Death of Microservice Madness in 2018 (есть перевод на хабре)

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

и потом помучившись с

несогласованность данных в системе

, думаешь такой — А не плохо было и с монолитом, может вернуть)

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

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

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

все программисты

это все равно что заявлять, если
— не мидл — не программист
— не синьер — не программист
— не архитект — не программист
...
претензию к компетентности можно поднимать бесконечно, а вот практического смысла в таком — не очень. Со словом «все» нужно обходиться крайне обережно.

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

Это вопрос жизненного цикла проекта (если точнее — продукта, а в общем виде «системы» (это если используем системный подход к делу)). В нормальном проекте ролью «программер» не обойдешся, там есть место очень разным ролям в первую очередь тем которые «проектируют», обладают видением «облика продукта», и тому подобное. И методологически правильно, что бы носители этих ролей спускали «вниз» представление о продукте (с нужной степенью детализации или фокусом внимания на определенных деталях для разных случаев) формируя «понимание продукта», «вовлеченность» и прочие интересные вещи..... но, тут на банальную документацию забивают, не говоря про ее актуализацию (согласно текущим изменениям).

А на счет

фичи в него уже не вставишь без долота.

не редкость когда это результат недостатка компетенций (и/или знаний) и в самом начале проекта )))

Ну вот DDD считается классикой

кто вам такое сказал?

Ну вот выглядит вполне живым training.dddeurope.com
Предложите другие комьюнити по архитектуре

плейлист за прошлые годы www.youtube.com/...​dbtRiqxZK9XBGqQ/playlists

Ну вот выглядит вполне живым

DDD живое, да. в .NET мире :)

И даже классикой да, можно назвать — основные идеи те же что в каноне 90ых:
моделируем мир в классах (по Аристотелю) и отождествлеяем объекты системы и модели домена (с выходом в частности на Rich model)

Предложите другие комьюнити по архитектуре

не интересовался такими. обычно хватало книг, статей, обсуждений.

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

плейлист за прошлые годы

и что? архитектура это ж не DDD :)

я вообще давний скептик в адрес всего что приводит к rich model в реализации, в пользу anemic model или DSL мотивов.
и насколько слышал, и недавно на доу даже рассказывали — в самой вотчине DDD — дотнете — накушались уже. хайп DDD так точно позади.
микросервисы вот еще на спуске на «дно разочарований»

но главное — а вам то зачем, для «embedded C++» — DDD точно чуждая штука

да, .NET это по Аристотелю
а SWIFT по Платону

да, .NET это по Аристотелю

не .NET, а «ООП от Страуструпа». О котором автор Smalltalk Алан Кей и сказал:
Я придумал термин «объектно-ориентированный», и вот что я вам скажу, я не имел ввиду С++. (OOPSLA ’97)

но да, оно, такое ООП сейчас доминирующее, хотя и не обязательное.

про SWIFT не знаю, не смотрел что там.

по основным и живым «энтерпрайзным» архитектурам как-то встретил коллекцию, чел для себя подбивал итоги последних 10-15 лет. Но пока отложил для чтений в свободное время, задачи читать лекции по архитектурам пока нет :)

я не читала Страуструпа, только Шилда
мы же о .NET говорим? почему вы тему меняете?

хотя и не обязательно

моя позиция такова: поскольку это проффесионализм и «энтерпрайзность», то результат должен быть ожидаемым. Сроки часто прощаються. И я, вспоминая С, слабо себе представляю что-то типа binance.com, не будь бы этой «эволюции»

мы же о .NET говорим? почему вы тему меняете?

Я о DDD говорил, и пару росчерками о его истории. Почему меняете тему на .NET?
на .NET можно проектировать и по другому. и проектируют и делают.
но DDD более всего полюбился именно в среде .NET

поскольку это проффесионализм и «энтерпрайзность», то результат должен быть ожидаемым.

что-то там 35% проектов проваливаются и по бюджетам и по срокам.

И я, вспоминая С, слабо себе представляю что-то типа binance.com, не будь бы этой «эволюции»

это вообще не понял к чему :)

ну это можно безконечно делать, Lead

по основным и живым «энтерпрайзным» архитектурам как-то встретил коллекцию, чел для себя подбивал итоги последних 10-15 лет

 Не это?
herbertograca.com/...​-architecture-chronicles
Если нет — буду благодарен за линку

свифтом деньги приходят каждый месяц)

то уже IBAN
или это для частных лиц?
я уже год как закрыла ЧП, наличкой платят, идет документальная проверка

Это когда из-за границы пришло не столько, сколько обещали — надо просить в банке свифтовку. Вообще — не знаю разницы, кто из них чем там заведует.

а уже видимо и не узнаю

но главное — а вам то зачем, для «embedded C++» — DDD точно чуждая штука

Да вот как надо сделать гейтвей между несколькими стандартами с разной логикой и разным железом — тут и гексагональная архитектура из ниоткуда появляется, и реактивный месседжинг (который в энтерпрайзе переизобрели лет через 20 после телекома), и множественное наследование с темплейтами — ужас джавистов.
А у соседей вообще классика — представь себе, сколько ограниченных контекстов в функциональности WiFi роутера со всеми VPN и торрентами. А оно все должно вместе работать и в упрявляющем монолите, и в вебе.

a DDD тут при чем?

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

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

да много их. главное ж
пусть безобразно но зато единообразно.

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

и множественное наследование с темплейтами — ужас джавистов.

а оно точно надо, множественное то наследование? ;)
а-а-а, ну когда архитекторы наастронавтили то конечно, куда ж без него...
или когда выбранная методология не позволяет по другому.

например

А у соседей вообще классика — представь себе, сколько ограниченных контекстов

ну да, тяжело.
откажитесь просто от мышления контекстами — сразу и попустит :)
от попытки решения задачи — для общего случая

ну а если взяли «DDD» — ну да, мужайтесь теперь, вскипайте мозгами.

к упомянутой статье 2012 я оставил простенький комментарий, что-то типа

есть два основных типа мышления
субъектно-объектное и процессно-ориенитированное

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

rich model — это для первого типа
anemic model — для второго

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

Держи
www.etsi.org/...​0/ts_10252703v010701p.pdf
Это надо заимплементить (всю логику поверх почти голого месседжинга от железа) и слепить вот с этим
trac.pjsip.org/...​epos/wiki/PJSIP-Datasheet
(там можно глянуть список стандартов)
Предложи инженерное (не аналитическое) решение. За 10 минут)

За 10 минут)

даже открывать не буду.
вы же не будете решать мои проблемы за 10 минут, верно?
с какой стати мне решать — ваши?

тем более железячные какие-то.

я копал в сторону DDD, мне это надо впрямую по моему домену — если вам кажется что этот энтерпрайзовый подход вам поможет для embedded (хотя он и в энтерпрайзе он глючит) берите и не сомневайтесь.
все равно все учаться только на собственных ошибках

Проблема уже решена.
При этом Вы считаете, что понимаете ее суть, сложность, и какие нужно применять методы.
На чем Ваше понимание основывается?

При этом Вы считаете, что понимаете ее суть

я даже проблемы вашей не знаю, откуда мне знать ее суть???

На чем Ваше понимание основывается?

об ОО проектировании и частном случае — DDD?

из того что я изучал, с 90ых, разные подходы в ОО проектировании, видел разные его виды, видел и последствия того, или иного вида проектирования
а уж сколько перечитано о разных проектах...

ну и на практике, применял.

и какие нужно применять методы.

история ООП как проектирования, так и программирования — это моя персональная история.
все прошло перед собственными глазами. начинал ведь когда его у нас еще не было :)
и о DDD поэтому только и могу повторить Экклесиаста:

Бывает нечто, о чем говорят: «смотри, вот это новое»; но это было уже в веках, бывших прежде нас.

и сейчас больше интересует вопрос
а какое вообще пространство концепций у ООП, чтобы могло появиться нечто новое чего не видел?
какова его аксиоматика?
и т.п.

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

Цитаты противоречат друг другу

Цитаты противоречат друг другу

как вы описали, так и выглядит.

Да вот как надо сделать гейтвей между несколькими стандартами с разной логикой

в общем случае конвертация данных и команд одного формата, в данные и команды другого формата.
а железо добавляет критичность выполнения команд во времени.
у меня в домене такой критичности нет — пользователь подождет, разницы между «100 мс» и «500 мс» — никакой.

насколько это сложно в вашем случае — понятия не имею.
но обычно это инженерный класс задач.

вам известны детали, переводящие вашу задачу в более тяжелый класс — «аналитического перевода китайского на английский»
может быть. все бывает, что вы столкнулись с такой задачей.

но DDD которое родилось с потребностей энтерпрайза — особенно хорошо это видно в первой главе книги Эванса — вам поможет?
сомневаюсь очень.

в общем случае конвертация данных и команд одного формата, в данные и команды другого формата.

Там разный control flow, и по сути надо писать юзерспейсный драйвер со всей логикой радиотелефонной базы. + потом появляется телефонная книга, история звонков и всякие плюшки. Потом добавляется собственная железка для управления аналоговыми телефонами.
И все это — в реал-тайме. Когда был звонок, и сняли трубку на одном из телефонов — нужно мгновенно погасить ринг на остальных. И начать делать кучу активностей по установке голоса. И в то же время прокидывать голосовые потоки других пользователей без перерывов.

но DDD которое родилось с потребностей энтерпрайза — особенно хорошо это видно в первой главе книги Эванса — вам поможет?
сомневаюсь очень.

Вряд ли помогло бы — там скорее когда несколько команд проект делают. А вот гексагоналка — самое оно.

Там разный control flow, и по сути надо писать юзерспейсный драйвер со всей логикой радиотелефонной базы. + потом появляется телефонная книга, история звонков и всякие плюшки

не сталкивался с такими задачами.

И все это — в реал-тайме

но энтерпрайзные архитектуры обычно игнорируют проблемы с временем выполнения. главное — чтобы ничего не потерялось, и обеспечение асинхронности.
то есть — не реалтаймовые они. а железо, насколько слышал, требует строгости в этом вопросе — команду X можно подать после команды Y не раньше чем n ед времени, но не позже чем m

но далек, так что может ерунду написал :)

но типичная то боль, на практике тоже бывает
начиная с какого-то размера базы, нагрузки
«вычисление скидки покупателю» становится неприемлимо долгим.
и тут то и начинается ...:)
а все потому что — «DDD» правильное преправильное :)

А вот гексагоналка — самое оно.

да, она не навязывает «rich»
другое ее ж название «порты и адаптеры» кажется

Погуглил rich vs anemic.
Похоже, там 3 модели:
1) Smart UI из первой книжки по DDD
2) Anemic model (процедурщина)
3) Rich model (ООП)

Фаулер пишет, что пункт 2 платит за ООП, толком не используя его:
In essence the problem with anemic domain models is that they incur all of the costs of a domain model, without yielding any of the benefits. The primary cost is the awkwardness of mapping to a database, which typically results in a whole layer of O/R mapping. This is worthwhile iff you use the powerful OO techniques to organize complex logic. By pulling all the behavior out into services, however, you essentially end up with Transaction Scripts, and thus lose the advantages that the domain model can bring.

В общем, на ДОУ не читал, а из нета похоже, что это старый вопрос C vs C++ (или новый FP vs OOP?). На С быстрее начинать кодить, но сильно большой проект очень сложно дописать и поддерживать.

Anemic model (процедурщина)

ничуть

цитата:
... Анемичная модель предметной области устроена иначе. Классы объектов предметной области лишены поведения. Они имеют только конструкторы и методы доступа к данным. Единственное, что они реализуют — это отношения с другими объектами. Все поведение системы выносится в слой сервисов, реализованный поверх слоя модели предметной области.
...
Как мы рассмотрели выше, преимущества, которые дает моделирование системы в ООП-стиле при использовании анемичной модели предметной области нам по прежнему доступны. Возможно, что получить данные преимущества можно только при грамотной проработке архитектуры системы, в частности — интерфейсов между слоями, но это — соответствующая плата за более простую модель. Способность объектов прозрачно сохраняться в долговременной памяти так же не теряется. Как раньше объект сохранялся соответствующей командой в репозитории (Repository) или участке работы (Unit of Work), так и продолжает сохранятся. Синхронизация изменений внутреннего состояния объекта с хранилищем данных не зависит от того, как именно выполняется данное изменение — методом внутри класса объекта или методом сервиса.
Несколько слов в защиту шаблона «Анемичная модель предметной области» (Anemic Domain Model)

и никто не запрещает проектировать в терминах ООП сущности из которых состоят эти сервисы, как и их самих.
как никто не запрещает использовать разные виды коллекций вместо массивов.

и паттерны ООП, даже из классических от GoF вполне отлично тоже применяются.

просто, мы описываем «не рыбок в аквариуме», а систему обмолота типизированных данных, с учетом их связей.
anemic — это и есть эта «типизация» данных, после анализа домена.

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

другой вектор — ФПшный — мы формализуем сервисы в терминах вычислений.

Rich model (ООП)

«страуструпа» и «фаулеров» — Аристотеля.

ООП в общем случае никак не обязано использоваться для моделирования домена. Это примерно та суть статьи в пользу ФП — Существительные vs глаголы.
Но так как студентам лучше пояснять «на реальных примерах», а процессно-ориентированный подход имеет контринтуитивные элементы, то «победило» большинство.

но когда объекты — хранятся в реляционной БД, а не OODB, мы и сталкивается крепко с
Вьетнамом компьютерной науки
и программистами которые умеют работать только с ОРМами.
и там да, беда, переписать жирные объекты куда больней, чем написать сервис обработки операции, оптимизированный под свойства персистентного хранилища и характеристики самой операции.

это хлопские статьи естественно.
все еще интересней и объемней.
но «..., большинство и этого не знает» и годами повторяю

ООП это не математика, ООП, любое — это философия.
ну и естественно так как программисты в основной массе ее чураются, то и обсуждать дальше — малоконструктивно.
Выходит прямо
«Да я неверующий, я убежденный атеист, вот те крест, Бог мой не даст мне соврать!»

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

Да, так будет быстрее для маленького проекта, но на большом и долгом как минимум можно огрести, если софт для БД протухнет, и его надо будет поменять. А когда вместо ORM рукописный адаптер — в нем что угодно максимально легко делается и меняется.

Как цена быстрого старта проекта — получаем разделение данных и алгоритмов; а если алгоритмы завернуты в ООП с наследованием и паттернами — то еще и динамическое поведение, а тогда из кода вообще фиг поймешь, что происходит и кого чем обработают. 2 неочевидно зависимых иерархии для сложного домена — это уже страшновато.

Отдельно там последний пункт — о простоте переиспользования. Не знаю, как на практике, а в DDD рекомендовали в доменный слой пихать только исконно присущую домену логику, остальное — оставлять в слое приложения. По-идее, понатыкав стратегий в нужном месте, поверх того же богатого доменного слоя можно положить другое приложение с другой пользовательской логикой (а другой доменной логики быть в принципе не может — на то она и доменная).

Не совсем так, что rich, что anemic можно как жёстко прибить гвоздями к БД, так можно работу с данными вынести в отдельный слой. Это просто разные способы организации бизнес логики, в какой-то мере анемичная модель — это тот же транзакционный сценарий, только с ооп. Где сервисы описывают бизнес кейсы, а не логика рассредоточена по объектам доменной логики.

Противников/сторонников обоих подходов море, уже 10 лет бъются.

но если с anemic другого выхода и нет, то с rich приходится постоянно принимать решение об ответственности и месте для кода — сервис или сама модель?

в проектах с промежуточным решением — ActiveRecord это часто видно. когда AR разбухают, разбухают, бизнес-логика расползается между ними, переплетается с технологической логикой, и потом наступает жопа что при попытках оптимизации перформенса, что при изменении бизнес логики.
и вопли — надо было брать Hibernate/Doctrine! По DDD надо было!
да, если рич — то надо было

или — надо было делать сервисный слой, и бить по рукам за размещение бизнес логики в AR, и держать там только технологическую

а если не понимать разницы между domain model и persistence model, то только в простых приложениях беды не будет от их совмещения.

Противников/сторонников обоих подходов море, уже 10 лет бъются.

это да. потому что оба подхода имеют весомые плюсы.
и вполне успешно применяются.

Дык я ж не спорю. Шишки разные набиты на личном опыте ))
И понимаю обе стороны.

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

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

если софт для БД протухнет

Персистентными данными называют данные, срок жизни которых превышает срок жизни приложений работающих с ними.

так что — да пусть протухает. новый напишется.

А когда вместо ORM рукописный адаптер — в нем что угодно максимально легко делается и меняется.

зачем писать рукописный адаптер, для сложных изменений данных? с какой целью такое удорожание разработки?

а тогда из кода вообще фиг поймешь, что происходит и кого чем обработают

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

а в DDD рекомендовали в доменный слой пихать только исконно присущую домену логику

а чтобы выявить — какая логика исконно присуща или нет — что нужно?
а учитывая что бизнес и сам не знает, каких действий от него потребует внешняя среда, в виде рынка, ковида, государства, и т.п. — мы приходим в пределе к рассуждениям о смысле жизни.
и к «множественному наследованию»
были у нас птицы — которые летали
были у нас рыбы — которые плавали
вот их исконная суть.
и появляется у нас пингвин...
и ему на рассуждения о сути рыб и птиц плевать
и разработчикам по большому счету — тоже, им надо его впихнуть в рассуждения об исконной сути птиц и рыб к концу спринта.

или известная суть
так доярка доит корову
или корова доитьСЯ дояркой?

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

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

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

и даже дронов и роботов тогда мы сможем втолкнуть в наш код.

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

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

так что — да пусть протухает. новый напишется.

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

зачем писать рукописный адаптер, для сложных изменений данных? с какой целью такое удорожание разработки?

Там нет «такого» удорожания, если в бекенде логика. 5%, максимум 10%. А если, конечно, задача — только сохранять данные и делать статистику по ним — тогда да, наверное, удорожание.
Зачем — вот тут отписал dou.ua/...​ign=reply-comment#2036054

минимум, если начинающие — выносим всю бизнес логику используя паттерн Команда.

А как там с нотификациями, когда по событию с одной сущностью нужно обработать кучу других, на нее завязанных? Писать отдельный сервис?

а чтобы выявить — какая логика исконно присуща или нет — что нужно?

Время. И разработчики, которым не пофиг, что и кому они пишут.

Что значит небольшой адаптер? Зачем он висит? Какие операции над данными он позволяет совершать? От чего именно он отгораживает=ограничивает при работе с БД. С какой целью?

Как можно не лезть в домен при работе с данными, если правила работы с ними — часть домена?

Что значит зависимость логики от вендора? От вендора — чего?

Почему код прибит гвоздями к схеме БД так прочно, что его — куча такого?

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

С нотификациями как надо — так и делаются. Что паттернами ООП, если совсем плотный монолит, что очередями, что сервисами. Зависит от проекта.

Разработчикам Тяжелее править архитектурую астронавтику и особенно — ошибочный результат анализа домена, чем линейный код.

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

Что значит небольшой адаптер? Зачем он висит? Какие операции над данными он позволяет совершать? От чего именно он отгораживает=ограничивает при работе с БД. С какой целью?

Адаптер занимается:
* созданием, удалением и сохранением модификаций доменных объектов
* сложными поисковыми запросами
Логика (основной код) работает с интерфейсом адаптера, а не с базой. Поэтому базу можно подменить или переформатировать. Можно кусок данных переместить в NoSQL в середине проекта, например — и доменный код от этого не изменится. Адаптер полностью энкапсулирует базу, приложение не знает, что там под низом: SQL, NoSQL, или текстовый файл, или заглушка.
С какой целью — написал в более раннем комментарии dou.ua/...​ign=reply-comment#2036054

Как можно не лезть в домен при работе с данными, если правила работы с ними — часть домена?

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

Что значит зависимость логики от вендора? От вендора — чего?

Если в коде есть SQL запросы, часть проекта вряд ли будет эффективно переносить на NoSQL. Если запросы оптимизированы под конкретную базу — могут быть проблемы с другой базой, и искать эти проблемы по всему коду. ORM тоже может быть недостаточно гибкой и недостаточно быстрой.

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

Работа с сырыми данными происходит только в адаптере. «Ports and Adapters» сегодня же упоминались, да? Все выше порта работает с доменными объектами.

И разработчики не телепаты, чтобы понять замысел архитекторов, и что исконная суть в что нет.

Вот по всей первой книжке DDD посыл что архитектор должен весь проект быть вместе с и одним из разработчиков.

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

Про адаптер только, разве что:
ну и монстр он у вас. Тут проработанные обобщения у ормов, по определению заточенные всего лишь под один тип баз — вынуждают лезть в их средства кастомизации, а то и кишки, а у вас адаптеру вообще все равно с каким даже типом БД работать.
Я о таких не слышал ещё...

а у вас адаптеру вообще все равно с каким даже типом БД работать.

Нет, адаптер у каждой базы свой. Имплементит общий интерфейс. alistair.cockburn.us/...​tecture-with-adapters.gif

Ну да, монстр — ыфкуил, к бд с разной идеологией — общий интерфейс.

Или лингвфранка — на котором только привет как дела и можно сказать.

Это не интерфейс к БД)
Это интерфейс для персистанса доменных объектов)

Это интерфейс для персистанса доменных объектов)

как этот интерфейс описывает такую типичную потребность:
получить доменные объекты Товар, количество проданных единиц которого за период времени X превышает количество проданных единиц этого же товара за период времени Y

unsigned GetSellCount(time_t from, time_t to);

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

unsigned GetSellCount(time_t from, time_t to);

смешно, да :)

unsigned

...
через 1 день новое требование
сгруппированные по производителям
через X дней — за исключением товаров проданных по промоакциям
через Y дней — только товаров от поставщиков с оборотом больше M
через ... дней —
и так пока приложение — в проде. и никто вам заранее не скажет об этом всем

что у вас станет с вашим интерфейсом?

а теперь, после лет в проде — а давайте переедем на другую БД!
надо только адаптер к ней написать для всех наших GetSellCount

Остальное — это доменная логика

а что такое — доменная логика по вашему, а не база?

сгруппированные по производителям
что у вас станет с вашим интерфейсом?

Ничего. Приложение знает для конкретного товара его производителя, и группирует. Это не логика базы, а логика доменной модели.
Для промоакций делается параметр Specification, который хранит набор свойств для фильтрования при поиске. Когда он создан, добавить в него очередное поле для нового типа фильтра — не проблема. И даже время в него затянется как поля.
unsigned GetSellCount(GoodsId id, GoodsSpecification spec);

а теперь, после лет в проде — а давайте переедем на другую БД!
надо только адаптер к ней написать для всех наших GetSellCount

 Да, и протестировать, склонировав сообщения на старую и новую базу. И да, одновременно можно кодить и отлаживать бизнес-логику (заменив базу заглушкой) и работать над схемой для базы. Так как логику можно запускать без базы.

а что такое — доменная логика по вашему, а не база?

Модель (сущности и правила) системы, с которой работает бизнес.

Приложение знает для конкретного товара его производителя

откуда оно это знает? где хранится эта информация?
два способа:
либо захардкодили, либо — в БД

Это не логика базы, а логика доменной модели.

мне надо согласно доменной логике запросить данные из базы.
базу вы спрятали за интерфейсом аля — print «Hello world»

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

И даже время в него затянется как поля.
unsigned GetSellCount(GoodsId id, GoodsSpecification spec);

начали продавать новый тип товара.
что будет с GoodsSpecification?

который хранит набор свойств для фильтрования при поиске

кто фильтрует, приложение или БД?

Когда он создан, добавить в него очередное поле для нового типа фильтра — не проблема

так и сейчас — какие проблемы?
вот с адаптером ограничивающим доступ к возможностям БД, да, проблемы. даже с ORMами — проблемы.

Так как логику можно запускать без базы.

ну это да, байку эту на любом докладе по DDD можно услышать :)
только в этих тестах отрицательных остатков не бывает.
а на проде они — есть :)
и как вы без базы, заглушками, смоделируете ситуацию?

Модель (сущности и правила) системы, с которой работает бизнес.

а кому нужна система без — данных?

и почему код запрашивающий данные не является доменной логикой, а — «списки фильтров» являются?

откуда оно это знает? где хранится эта информация?
два способа:
либо захардкодили, либо — в БД

 В БД. Для сгруппированной по производителям выдачи всех товаров все равно надо будет поднять их все поднять.

начали продавать новый тип товара.
что будет с GoodsSpecification?

Ничего — это набор флагов для параметров поиска типа «промо», «начало продаж», «конец продаж». Из DDD.

кто фильтрует, приложение или БД?

Адаптер создает запрос в БД исходя из параметров фильтра, результат возвращает в приложение в читаемом виде.

а на проде они — есть :)

1) И откуда они берутся, если пишет один поток, и если операции добавить/уменьшить завернуты в отдельные команды, проверяющие остаток? Адаптер проверяет, что реально есть товар, который он уменьшает. И отлавливает баг.
2) А еще — можно сделать event replay с заглушкой вместо адаптера базы, которая будет считать остаток по данному товару, и сассертит как только он уйдет в минус. Будет видно, кто это сделал.

а кому нужна система без — данных?

Система описывает взаимодействия. Ее нужно закодить. На это нужно время. Предлагаете не кодить, потому что данных от реальных пользователей еще нет, а значит — система никому не нужна?)

и почему код запрашивающий данные не является доменной логикой, а — «списки фильтров» являются?

Потому что фильтры — это свойства доменных объектов, как «время покупки» или «промо». И фиг сделаешь магазин без «покупки» и «промо». А поля в базе — не свойства домена, так как один домен можно посадить на разные базы с разными полями, и покупателям пофиг, что там как в базе.

В БД. Для сгруппированной по производителям выдачи всех товаров все равно надо будет поднять их все поднять.

ну спасибо.
а как потом переехать на БД которая не умеет этого делать?

Ничего — это набор флагов для параметров поиска типа «промо», «начало продаж», «конец продаж». Из DDD.

то есть «промо» акции это одного типа что и «начало продаж»?

Адаптер создает запрос в БД исходя из параметров фильтра, результат возвращает в приложение в читаемом виде.

ну да, ORM тоже самое делает.

Адаптер проверяет, что реально есть товар, который он уменьшает.

то есть доменная логика просочилась в адаптер. он знает о правиле — что остаток не может быть меньше нуля, еще и знает как получить эту инфу.

И откуда они берутся, если пишет один поток

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

я по крайней мере о такой гениальной в своей просте идее еще не слышал :)

Адаптер проверяет, что реально есть товар, который он уменьшает.

на чем проверяет, на заглушке БД?

А еще — можно сделать event replay с заглушкой вместо адаптера базы

много чего можно сделать.

Система описывает взаимодействия

Информационная система (ИС) — система, предназначенная для хранения, поиска и обработки информации, и соответствующие организационные ресурсы (человеческие, технические, финансовые и т. д.), которые обеспечивают и распространяют информацию

я о таких системах.
утрировано — об обработке информации. является ли информация описанием взаимодействий, или еще чем — второй вопрос

Потому что фильтры — это свойства доменных объектов,

а «количество проданного объекта за период Х» это тоже свойство этого объекта? А «от поставщиков имеющих статус партнеров» — тоже свойство доменного объекта?

А поля в базе — не свойства домена

они хранят — информацию. без которой «свойства домена» так и останутся на диаграмме архитектора.

так как один домен можно посадить на разные базы с разными полями

да хоть на сто пицот баз.

Вопрос останется тем же — чем доменная логика отличается от логики обработки информации

а как потом переехать на БД которая не умеет этого делать?

Что не умеет делать? Прочесть все товары?

то есть «промо» акции это одного типа что и «начало продаж»?

Нет, это разные поля в структуре, описывающей настройки поискового фильтра.

то есть доменная логика просочилась в адаптер. он знает о правиле — что остаток не может быть меньше нуля, еще и знает как получить эту инфу.

Да, адаптер имплементит интерфейс, описанный в терминах домена, и будет содержать трансформации с доменной логикой, в частности — почти всю поддержку инвариантов. Неотрицательность остатка — инвариант.

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

Он не может писать прямо в базу мимо адаптера, а адаптер висит на очереди сообщений, которая сериализует записи в один поток.

на чем проверяет, на заглушке БД?

На самой БД если это адаптер БД, на заглушке — если это адаптер заглушки.

а «количество проданного объекта за период Х» это тоже свойство этого объекта? А «от поставщиков имеющих статус партнеров» — тоже свойство доменного объекта?

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

они хранят — информацию. без которой «свойства домена» так и останутся на диаграмме архитектора.

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

Вопрос останется тем же — чем доменная логика отличается от логики обработки информации

Передергивание. Или у Вас база занимается в основном «обработкой информации»?

Прочесть все товары?

все пару сотен тысяч — потому что не умеет фильтровать?

это разные поля в структуре, описывающей настройки поискового фильтра.

у промо акций так же бывают свои спонсоры.
которым интересно добавить к выборке
а по моим промоакциям — сколько товару у вас продано?

Да, адаптер имплементит интерфейс, описанный в терминах домена, и будет содержать трансформации с доменной логикой, в частности — почти всю поддержку инвариантов.

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

Неотрицательность остатка — инвариант.

угу, успехов в реализации «зависимых типов» :)

Он не может писать прямо в базу мимо адаптера

захочет — сможет.

Думаю, это — другие доменные объекты.

нет, это те же объекты.
так же как и вы тот же в метро, в лесу, и в своей квартире.

но в выборку
в день икс, в время игрек в лесу — вы попали,
а в выборку
в день икс-два, в время игрекдва в метро- нет

и вы еще даже не думали купить вещь зет.
но через полгода — купите, и попадете в выборку купивших вещь зет в 2021ом году.

так бывший в лесу и купивший вещь — это свойство, характеристика объекта?
и другой ли объект?

а о полях в базе бизнес ничего не знает и знать не хочет.

он и доменных сущностях знать не хочет.

а без кода доменной логики вообще не будет бизнеса.

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

Или у Вас база занимается в основном «обработкой информации»?

а чем ей еще заниматься?

собственно все ПО этим и занимается.

Передергивание

не, просто попытка поковырять догмы о DDD :)

все пару сотен тысяч — потому что не умеет фильтровать?

Так было же требование — выдать все товары, отсортированные по производителю, при каком-то условии. Все равно идет чтение всей таблицы. Если можно фильтрануть — можно фильтрануть через спецификацию. А если отсортировать — то в оперативке быстрее будет.

у промо акций так же бывают свои спонсоры.
которым интересно добавить к выборке
а по моим промоакциям — сколько товару у вас продано?

Еще одно поле в структуре (скорее, спецификация промо сама становится структурой) — ид спонсора промо. Все равно кода в приложении для поддержки этих новых требований будет наверняка больше. Если прямо фронтэнд не формирует запросы в базу.

угу, успехов в реализации «зависимых типов» :)

Это что-то сложное. Можете расшифровать реальным примером для магазина?

захочет — сможет.

У него нет доступа.

нет, это те же объекты.
так же как и вы тот же в метро, в лесу, и в своей квартире.

«количество проданного объекта от поставщиков имеющих статус партнеров» не то же самое, что «объект». И даже «выборка объектов» не то же, что «объект».

он и доменных сущностях знать не хочет.

Тодга он часто будет получать не то, что хотел, потому что его будут неверно понимать.

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

Без сайта и бекенда интернет-магазин не приносит прибыль. Без серверов склады стоят. А потеря истории продаж за прошлый год — неприятность.

а чем ей еще заниматься?

Хранением информации)))

Все равно идет чтение всей таблицы

кто вам сказал что будет fullscan?

то в оперативке быстрее будет.

а БД не в оперативке работает?

Если можно фильтрануть — можно фильтрануть через спецификацию

так скажите это БД, она на это заточена, и сделает быстрее, чем ваш код

Все равно кода в приложении для поддержки этих новых требований будет наверняка больше.

это если вы сами все делаете, своим кодом
а если делегируете эту работу БД — то там пара строк

Это что-то сложное.

та же проблема — остаток надо запросить у БД. или брать на себя ее функции.

«количество проданного объекта от поставщиков имеющих статус партнеров» не то же самое, что «объект»

вы получите коллекцию объектов. конечно коллекция не тоже самое что объект.
ну в общем случае у вас будет коллекция пар — объект-количество

Тодга он часто будет получать не то, что хотел, потому что его будут неверно понимать.

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

Без сайта и бекенда интернет-магазин не приносит прибыль

да. главное — здание супермаркета. а что в нем — ерунда, не стоящая внимания.

Без серверов склады стоят.

вообще-то нет. по крайней мере наблюдал как работают при таких форсмажорах.

А потеря истории продаж за прошлый год — неприятность.

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

так скажите это БД, она на это заточена, и сделает быстрее, чем ваш код

Так адаптер и скажет БД, но никто кроме него не знает, как сказать, и не завязан на схему. То есть, схему можно менять, не меняя основной код.

это если вы сами все делаете, своим кодом
а если делегируете эту работу БД — то там пара строк

Куча кода, чтобы сделать ЮИ, бекенд, и их взаимодействие для поиска спонсором своих товаров. 100 строк в адаптере БД — ничто по сравнению с остальной работой для этой фичи.

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

Вопрос в размере. DDD появилось для невменяемых проектов, на которых один человек не может нормально осознать все требования.

То есть, схему можно менять, не меняя основной код.

самый древний метод — стягивание всего SQL кода в один класс уже это делал.

100 строк в адаптере БД

или построителе запросов, с названием методов в терминах домена

речь то о другом — о том где содержится знание о связях объектов.
объект что-то знает о спонсоре? нет.
спонсор знает? нет.

информация о связи находится в БД.
так почему ей бы не использовать эту связь?

для этой фичи

конкретно у меня — попросили всего лишь отдавать им csvшку

но согласен, если если еще и UI, то будет много.

DDD появилось для невменяемых проектов

это да. в силу закона Конвея, а не каких-то технических преимуществ

самый древний метод — стягивание всего SQL кода в один класс уже это делал.

Так чем тогда Ваш один класс лучше или проще моего адаптера?

речь то о другом — о том где содержится знание о связях объектов.
объект что-то знает о спонсоре? нет.
спонсор знает? нет.

Да, объект знает о спонсоре (можно лениво инициализировать связь, если редко нужно). Спонсор о своих объектах — смотря, часто ли это нужно в приложении. Rich domain model.

Так чем тогда Ваш один класс лучше или проще моего адаптера?

тем что его ответственность описывается одним предожением
скрытие кода зависящего от БД

а у вашего адаптера — ого сколько ответственностей.
больше чем у тяжелых ORMов в лице Hibarnate/Doctrine

поэтому и написал — монстр которого не видел и не слышал о таком.

Да, объект знает о спонсоре

умный какой.
а о своих покупателях он тоже знает?
а о тех кто его вернул?
а о поставщиках и разных входных ценах — тоже знает?

Rich domain model.

это точно для «все всё знают обо всех»?
надо будет перечитать

можно лениво инициализировать связь

это динамическая связь. еще и зависящая от момента времени, в один момент она есть, в другой ее нет.

скрытие кода зависящего от БД

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

умный какой.
а о своих покупателях он тоже знает?
а о тех кто его вернул?
а о поставщиках и разных входных ценах — тоже знает?

Если мы говорим о товаре — то о покупателе может знать, как и о датах поступления в сервсис. Если мы индивидуальные единицы товара не отслеживаем — то, вероятно, нет смысла нагружать — появляются служебные классы связок покупатель-товар-цена и поставщик-товар-цена-количество. По крайней мере, так в той самой первой книжка по DDD. У поставщика и у покупателя списки таких связок (вероятно — с ленивой инициализацией). Вообще — надо смотреть конкретно по требуемой функциональности.

это динамическая связь. еще и зависящая от момента времени, в один момент она есть, в другой ее нет.

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

У моего —
энкапсуляция БД

Ну да. То есть повторение кучи функционала бд. Я ж так и понял. Монстр.
гуглил тут, наткнулся на древний пост.
rsdn.org/forum/design/3406168.1

Может я его тогда его ещё читал, а то прямо как вместо меня подбили итоги. И даже концовка — «моя»

Вам надо исторические
связи

Сплошь и рядом. Почти всегда.
В текущем проекте — тоже.

Если делать по рич, тогда либо у методов должно быть параметром — время на которое нужно значение атрибута,либо репозиторию указывать,чтобы выдал объекты в состоянии на время х.
А как он тогда их кешировать будет?

И операции над объектами надо производить с учётом — времени.

И это не мне надо. Это бизнесу почему то постоянно надо.

Вам надо исторические
связи
Сплошь и рядом. Почти всегда.

Читаю ваш сра...дискуссию. Интересно.
Но вот тут поддержу Сергея.
Исторические связи и данные о причинах для нормального продукта маст хев. Бизнесу всегда нужны выгрузки за прошлые месяцы/годы и всегда нужно знать не только данные, но и почему эти данные вообще есть.
Если это не какаято хипстеркая платформа для подсчета лайков через бигдату и машинленинг.

Если делать по рич, тогда либо у методов должно быть параметром — время на которое нужно значение атрибута,либо репозиторию указывать,чтобы выдал объекты в состоянии на время х.
А как он тогда их кешировать будет?

И операции над объектами надо производить с учётом — времени.

И это не мне надо. Это бизнесу почему то постоянно надо.

Аналитика? Она точно в том же приложении, что и операционка?
Возможно, тут два параллельных субдомена, которые и делать стоит раздельно — более простую операционку с текущими состояниями, и аналитику с историей.
(Нет опыта, чтобы утверждать, но такая вот забавная идея)

Она точно в том же приложении, что и операционка?

для принятия решения «о товаре» оператору требуется посмотреть «остатки в разных разрезах».

Возможно, тут два параллельных субдомена

это один домен.
но в больших пребольших системах, где роль оператора все уже и меньше, вплоть до уровня работы «вместо ксерокса» — да, делают разные приложения, вплоть до АРМ (автоматизи́рованное рабо́чее ме́сто) для каждой должности оператора. или создают наборы переключаемых UI, где одновременно видно в лучшем случае «20%» возможностей системы.

это один домен. но я почти впрямую давно применяю при анализе и проектировании:
«Фактов не существует. Существуют только интерпретации» Ницше
«Мир есть совокупность фактов, а не вещей.» Витгенштейн

Поэтому хранение данных о «первичных фактах» должно быть как более оторванным от представлений кого-либо «об исконной сути» доменнных объектов. нет ни у чего никакой сути. суть — это всего лишь удобный язык оперирования, контекстно-зависимая штука.
А чем больше у заказчика ролей — тем больше точек зрения — интерпретаций на то что такое домен, и что этой конкретной роли от домена надо.
продолжая выше пример — для парикмахера человек — это просто голова с волосами. а для клининга — человек это то что ходит в грязной обуви. а для бухгалетра — то что деньги приносит.
а компания — одна. и про исконную суть человека — никто в ней не знает ничего. а я что ли, будда всеведующий, проникший взрором просветленным в суть вещей мира? ну так суть все равно — пустота-шуньята :)
а архитекторы, канонические, — обычно теисты(сами того не зная, не рефлексируя о своих пристрастиях). вот и выдумывают «DDD» — отвечающее их мироощущению :) и типа знают о сути.
конечно не все так тупо, если DDD, то копать в сторону bounded context.

Хотя, движуха в сторону микросервисов, serverless порождает архитектов которые уже и не теисты, и которые вынуждены мыслить — процессно. процессами домена, а не его сущностями.

а процессы домена — очень хорошо выявляются с помощью User strory. и если мы не ставили себе задачу описать «суть вселенной заказчика», ее онтологию, то вот и получается — «аджайл проектирование» — если поняты атомы домена, анализировать на уровне абстракции минус 1, то мы можем не строя всей этой агроменной картины доменных объектов, их поведения, правил, и т.п. — начать делать фичи

собственно микросервисные системы — во многом так и делаются, и косвенно навязывают такой подход к проектированию — атомарность, целостность изменения данных — вот что нужно, а не метамодели сущностей. с которыми мы можем прогадать(и прогадаем, абстракции протекут обязательно), которые могут измениться потому что «птиц» и «рыб» придется менять на «летающих» и «плавающих». — а такое изменение при ортодоксальном ООП — это переписывание системы практически с нуля.

более простую операционку с текущими состояниями

да, эти АРМ потому и делали, что они простые, их может делать отдельная команда «крудошлепов», и им требуется только маленькая часть данных и знаний о них.
а БД у всех — общая.
Для более навороченной аналитики — поднимаются «OLAP-кубы», BI report systems (работал с QlikView, крутая штука, самому такое писать, ой) — и это делают вообще другие команды

для принятия решения «о товаре» оператору требуется посмотреть «остатки в разных разрезах».

Не знаю, как вы называете софт, который работает автоматически и обслуживает магазин. По-идее, это — операционная поддержка. В отличии от аналитики. И кто такой «оператор»?

Там получается
1) автоматическая система:
* нужно только текущее значение полей
* чтение и запись в базу
* задачи рельного времени
* ошибки недопустимы
* потери данных недопустимы

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

По наборам сил (тех самых, которые формируют паттерны и определяют архитектурные решения) это вообще разные системы. Как и по требованиям к базе. Соответсвенно, думаю, тут надо и кодить дважды — простую богатую доменную модель для автоматической работы (без исторических данных и связей она не будет невменяемо сложной) над упрощенной базой с текущими данными, и умный фронтенд для аналитики, напрямую лезущий в хранилище истории изменений (без explicit domain model).

По базам, насколько я понимаю, варианты:
а) тупой и медленный: все кидается в основную базу, аналитика работает с реплики, обновляемой ночью.
б) посерьезнее: параллельные базы, упрощенная SQL схема (без истории — только с текущим спонсором) для автоматики, и журнал истории с посуточными слепками состояния (не знаю правильного названия, но думаю, такое давно существует) для аналитики.
Эта штука будет летать, так как:
* В основную рабочую базу никто не лезет с тяжелыми запросами (а винт-то таки один, и DMA с вечными двигателями не помогут головке читать и писать одновременно), и у нее простая схема.
* В исторической базе нет писателей, поэтому не нужны локи.

Оператор — office (employee) user. В отличие от home user.

Софт который обслуживает автоматически магазин — инвертаризацию как делает?

Про эта штука буде летать — делайте.
У меня не это главная проблема.
В энтерпрайзе так или иначе эти проблемы с DMA решаются. И не они главные.

Вообще, весь пост и ваши идеи какие-то низкоорувневые. A DDD куда делся?

Ну и — раз вам так видится — так и делайте.

инвертаризацию как делает?

Для инвнтаризации нужны исторические данные по всем бывшим спонсорам, или продажи за прошлый год? Я думал, там только текущий спонсор и текущий остаток.
Аналитика и инвентаризация как-то по-разному выглядят, не?

A DDD куда делся?

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

Для инвнтаризации нужны исторические данные по всем бывшим спонсорам

нужны — остатки.
в требуемых разрезах.
еще следом часто нужны — взаиморасчеты, в требуемых разрезах

Аналитика и инвентаризация как-то по-разному выглядят, не?

данные для них — одни и те же. ни первое ни второе без данных не работает.

но главное, обеспечение
drill down возможностей, с разнообразными разрезами, и непрогнозируемой на этапе разработки фильтрацией.
поэтому чем позже данные будут свернуты, то есть с потерей информации, тем лучше.

которое должно работать быстро и надежно.

как-то получается, и приемлимо быстро и приемлимо надежно даже у вебремессленниов.

у вас, с однопоточной записью на серверный HDD у которого одна головка — понятия не имею.
я не сталкивался ни с таким подходом, ни с таким железом.

у меня на добашнем компе даже 2 головки на 1 блин HDD (про SDD пока не буду упоминать)

те же сервера что покупал на предприятия — сразу шли с 4мя в райде (с зеркалированием+чередованием), с кеш памятью до гига и энергонезависимой системой поддержки остановки.

у вас на проекте денех что-ли нет на такие?

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

А DDD в той штуке

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

вопрос о DDD, как и любой другой методологии:
какие преимущества сколько стоят. за все придется платить — если преимущества окупаются — платите за них.
вот это будет — предметный разговор о DDD
недостатки DDD, то есть ту самую оплату я бегло упомянул. потому что видел как и сколько платили — интересовало и почему без этой оплаты — никак.
когда о недостатках, то есть чем придется платить не говорят, или отмахиваются, «это не существенно» — то это впариватели или идеалисты.

а «одна головка HDD» всего, поэтому многопользовательская система пишет в один поток — это уже низкоуровое.
купите на распродаже сервер. у меня один знакомый так подрабатывает — купил на ебае, домой два канала протянул, и сдает vpsки небольшим компаниям, которые работают с своим ПО в GUI терминалах(им выгодно, компьютерный парк у себя в офисах обновлять не надо). у него «головки HDD» — справляются.

данные для них — одни и те же. ни первое ни второе без данных не работает.

И как для инвентаризации играет позапрошлогодний спонсор или продажи месячной давности? Там же важно, сколько должно быть сейчас на складе, а не кто сколько купил?

но главное, обеспечение
drill down возможностей, с разнообразными разрезарыми, и непрогнозируемой на этапе разработки фильтрацией.

Для инвентаризации?

как-то получается, и приемлимо быстро и приемлимо надежно даже у вебремессленниов.

А я работал на проекте, у которого тупой поиск максимальных продаж по 10 ГБ дампу таблицы занимал 3.5 минуты. Через sed. Или 10 минут питоном. Про выдачу пользователям прямо из базы через select+join+sorted с постобработкой просто речи быть не могло — там самописные индексы и поисковики на С++. Потому что база будет 10 минут обрабатывать, а нужно — за две секунды.

а «одна головка HDD» всего, поэтому многопользовательская система пишет в один поток — это уже низкоуровое.
купите на распродаже сервер.

Локи еще забыли)
1) Если уже добыли несколько дисков в серверном железе — они вешаются в RAID0 для увеличения скорости ВСЕХ запросов в разы.
2) Чем быстрее работает диск, тем больше по сравнению с диском будут тормозить локи в оперативке.

По моногопоточной записи — вот в SQLite, вроде, ее нет. Пишут, что с Write-Ahead Logging быстрее остальных sj14.gitlab.io/...​bbench/#benchmark-summary по всем тестам. Может, потому, что локи не ставят?

вопрос о DDD, как и любой другой методологии:
какие преимущества сколько стоят. за все придется платить — если преимущества окупаются — платите за них.
вот это будет — предметный разговор о DDD

 Вернемся. DDD помогает просто описать текущее положение дел, и накодить тот же магазин со складами вменяемо. Не учитывая историческое данные, нужные только аналитике.

Аналитику есть смысл делать над рид-онли базой (чтобы не мешать проду) вообще без доменной модели (transaction scripts прямо из фронтенда). Тогда новые скрипты проще всего шлепать.
Можно внести простенькую обертку над базой, если захочется не искать по коду запросы при смене схемы. Где тут вообще анемичная модель и ОРМ?

И как для инвентаризации играет позапрошлогодний спонсор или продажи месячной давности?

вполне могут влиять и годичной.
у меня например сейчас критичность данных до года.
то есть некоторые агрегации охватывают такой период.
есть 3ехмесячные.
смысла оптимизировать, в какие-то свернутые значение — пока нет.
да и не угадаешь, потому что некоторые появились с месяц назад
появятся и еще. всегда.

Там же важно, сколько должно быть сейчас на складе, а не кто сколько купил?

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

у которого тупой поиск максимальных продаж по 10 ГБ дампу таблицы занимал 3.5 минуты. Через sed.

ну, если операторы могут пользоваться sed — то почему бы и нет :)
когда им надо получить 5 итоговых цифр, для принятия решения в своих действиях — то почему б нет, пусть берут sed.

там самописные индексы и поисковики на С++.

не сталкивался. когда-то, да, в древние времена, видел такие системы.

Локи еще забыли)

они в памяти. диск ни при чем.
на ютьюбе есть доклады, про то как устроены локи в БД.

вот в SQLite, вроде, ее нет

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

Может, потому, что локи не ставят?

лучшее средство от насморка — гильотина.

можно еще на ассемблере написать магазинчик, и показать преимущество перед питоном + джнага в скорости работы.

DDD помогает просто описать текущее положение дел, и накодить тот же магазин со складами вменяемо.

позволяет конечно. не хватало чтобы не позволяла.
назовите мне живую парадигму которая этого не позволяет :)
кому она нужна тогда?

Не учитывая историческое данные

не исторические, а — историчность изменений данных.
Даже фамилия — может поменяться, и нередко система и это учитывает.

Аналитику есть смысл делать над рид-онли базой

Для расчета скидки «здесь и сейчас» — вам нужны те же сырые данные что и для аналитики.
в случае нерешаемых тормозов — делается мастер-слейв, пишем в мастер, читаем из слейв. но данные там все.

Можно внести простенькую обертку над базой

вносите.
я уже все сказал:
дрейв от «DDD» в сторону anemic видел много раз, обратного — не помню.
приближение к возможностям БД видел много раз, вплоть до выноса бизнес логики в ХП видел тоже немало. Как и кастомизацию универсальных возможностей ORMов
обратного — как-то не припомню.

Где тут вообще анемичная модель и ОРМ?

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

вообще без доменной модели

делайте без доменной модели :)
кто ж вам доктор.
мне она — помогает. минимум — ориентироваться в коде.

Тогда новые скрипты проще всего шлепать.

«Неважно что ваша программа умеет делать сегодня. Важно что она будет уметь завтра»

Нашлепать скриптов — а потом их править — приблизительно та же работа что и с копипастой потом.
Даже в презренном WP + WooСommerce так не делают.
Но вы — делайте.
и операторы пусть в sed все делают.
у вас же получилось на одном проекте — ну вот, апробированный опыт — применяйте и в текущем и в будущем :)

я в «складах» на разных системах с конца 90ых. и на разных ролях. был и в цеху у аналитиков, и у проектировщиков, и в разработке и в саппорте. у меня просто другой опыт. апробированный.
ваш круче, вы и делайте. мне же напрочь непонятно, как решать обычные задачи что решал — с вашими тезисами об однопотоке, sed, и «головки HDD»

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

ну, если операторы могут пользоваться sed — то почему бы и нет :)
когда им надо получить 5 итоговых цифр, для принятия решения в своих действиях — то почему б нет, пусть берут sed.

Нет, это мы просто взяли табличку сравнить скорость питона и С++)))

Для расчета скидки «здесь и сейчас» — вам нужны те же сырые данные что и для аналитики.

А не проще для юзера ввести рейтинг со скидкой? Зависящий от накопленной суммы покупок?

Скорость разработки — важнее скорости выполнения — в моем домене.

Ну у меня наоборот — пока питон не съест свой хвост, а жаба не задавится — о полумесяце с крестами никто и не заикнется.

А не проще для юзера ввести рейтинг со скидкой? Зависящий от накопленной суммы покупок?

в сумме покупок могут участвовать не все товары
в сумме покупок на разные товары может быть разная скидка
скидка может поменяться задним числом,
..., ..., ..., ..., ..., - только описание одного нашего расчета занимает несколько страниц бизнес аналитического описания, и с 10ок параметров которые могут поменяться в будущем только интуитивно.

а у каждого развитого магазина — полно такого.

P.S.
чисто случайно, интернет принес.

Преамбула — реальные проблемы редко всплывают в докладах, правильных книжках, в самопиаре консалтеров у которых «никогда не было фейлов» и т.п. по многим причинам (у меня во внутренних чатах тоже подобного уже накопилось, и жалобы пользователей, и операторов. но свое публиковать — не буду конечно :))

вот одна всплыла, и то, быстро «исчезла»
— так, я принял волевое решение удалить твит: популярность мне не нужна, а такое внимание слишком разбередило мою тревожку

но другие успели, и я и себе перепостил.

История про «Остатки»
там скриншот, поэтому линк:
skynin.xyz/...​zni-v-razrabotke-skladov

Финал:
— А чем закончилось-то? Уволились всей командой?)
— В итоге они все уволились, да.

кто не живет в этом — наверное и не поймет — обыденности ситуации.
кто живет — сам такого понараскажет.

большинство программистов мира «кровавого энтерпрайза» вот таким и занимаются.

После этого прийдут молодые и просветленные и за джва года все перепишут на serverless или scala + akka

поэтому не нужны локи

Локи не обязательно, а даже и не нужно держать в базе. Их можно вынести на уровень приложения. В данном случае — на уровень бекенда того, что ты описал как «автоматическая система».

Я о том, что в основной R/W базе при многопоточном доступе идет serializable isolation, подразумевающий мютексы (даже для читателей), которые будут замедлять работу под нагрузкой. Для RO базы мютексы не нужны — даные константные, поэтому доступ read uncommitted и все чтения без блокировок в ОС. + кеш проще и без тормозов — не нужно синхронизировать кеши потоков.
www.youtube.com/...​tch?v=TFETtW86zAc&t=1163s например

Просто не надо делить на меньшие куски части, которые требует одной транзакции.

Грубо говоря, открыл транзакцию, насрал в БД, что-то пошло не так — откатил транзакцию, и все красиво и цело.

Делаешь чекаут корзины на 10 позиций.
прочитал остаток товаров со склада , везде 1+ — уменьшил количество , проверил баланс остаток по счёту — все ок, записал списание позиций и остатка по счету. Закинул все в begin Tran/commit Tran. Смотришь остатки в конце месяца на складе в −1 по некоторым товарам где-то остатки по счету отрицательные.

И Монолит и логика в базе и втранзакции все,но данные не такие как ожидаем.

Ну так вы пропустили резервирование. Кидаете запрос на резервацию в отдельный сервис, он уменьшает все сразу в одной транзакции и пишет в отдельную табличку чего уменьшил. И возвращает ответ — есть все или нету.
Потом если подтверждения не было в течении часа — откатывает.

сервиса отдельного нет. у меня монолит и те списания, что я делаю уже внутри begin tran/commit tran в том кейсе, что я описал, а остатки кривые(отрицательные) все равно.

Так это не проблема монолита/микросервиса, это проблема архитектуры. Которая может быть как успешно решена в любом из кейсов, так и успешно зафейлена.

Так это не проблема монолита/микросервиса, это проблема архитектуры.

архитектура тут не при чем.
я описал выше практический use cases со всеми вводными. и закинул в транзакцию(дефолтную read committed) как вы сказали. все логика в хранимке и одной базе, только таблички разные. где проблема, почему остатки отрицательные, вы же обещали что все будет консистентно достаточно закинул в транзакцию и усе?

Грубо говоря, открыл транзакцию, насрал в БД, что-то пошло не так — откатил транзакцию, и все красиво и цело.
дефолтную read committed

может дело в уровнях изоляции транзакций?

если не хочется повышать, то определитесь с данными на которых лочиться, и расставьте FOR UPDATE и FOR SHARE

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

SERIALIZABLE уж очень присаживает БД...

я на собеседованиях не раз слышал
— как вы обновляете счет покупателя и остатки на складе?
— ну как как, просто апдейтом
— без блокировок?
— а что это?

так и есть, если ошибиться и у конкуретных сессий допустить, что чтение не будет сделать lock не совместимый с уровнем изоляции конкурентной сессий, data corruption все равно не избежать,потом, когда после добавление for update , возникает порядок чтения таблиц противоположный в разных флоу начинается бесконечная борьба с дедлоками. а еще дедлоки могут возникнуть из специфики обновления индексов (key lookup index) или вот такая дичь
support.oracle.com/...​e Products/1570285_1.html
technologyinsightscoffee.wordpress.com/...​/deadlocks-in-sql-server

В конце выясниться, что надо привлечь магистров сакраальных знаний(aka DBA) что бы разгрести всю эту дичь, что происходит когда бизнесс логика в базе внутри транзакции. а еще скейла там никакого не будет уж почти наверняка.
Ну и само собой те ребята, что пишут типичный enterprise код(вотчина РСУБД), на java/php/c# разбираются в этом куда меньше, и наломают дров со стейтом куда меньше чем если сделают сагу для роллбека и optimistic locking для того что бы предотвратить data corruption.

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

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

Ну и само собой те ребята, что пишут типичный enterprise код(вотчина РСУБД), на java/php/c# разбираются в этом куда меньше,

тут да. примерно как
jQuery знаю, про JavaScript слышал, но не использовал

Hibernate/Doctrine знаю, про SQL слышал, но использовал последний раз на лабе в институте

и наломают дров со стейтом куда меньше чем если сделают сагу для роллбека и optimistic locking для того что бы предотвратить data corruption.

понятно.

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

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

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

но вижу вы уже на низком старте

ну, раз вы телепат, то и правда, пора резюмировать:

от проблемы «простоты обеспечения целостности данных в рсубд»

но Сага — это не для простоты обеспечения целостности, а когда:

Есть приложение, к которому применялся паттерн Database per Service. Теперь у каждого сервиса приложения есть своя собственная база данных. Некоторые бизнес транзакции охватывают сразу несколько сервисов, так что нужен механизм, обеспечивающий согласованность данных между этими сервисами.

Например: давайте представим, что мы разрабатываем интернет магазин, где у клиента есть кредитный лимит. Приложение должно гарантировать, что новый заказ не превышает кредитный лимит клиента. Так как Заказы и Клиенты — различные базы данных, то приложение не может использовать локальные ACID транзакции.
...
Сага представляет собой набор локальных транзакций. Каждая локальная транзакция обновляет базу данных и публикует сообщение или событие, инициируя следующую локальную транзакцию в саге. Если транзакция завершилась неудачей, например, из-за нарушения бизнес правил, тогда сага запускает компенсирующие транзакции, которые откатывают изменения, сделанные предшествующими локальными транзакциями.
...
Сага имеет следующие недостатки

Модель программирования становится более сложной. Например, разработчики должны проектировать компенсирующие транзакции, которые отменяют изменения, сделанные ранее в саге.
(конец цитаты перевода на хабре microservices.io/patterns/data/saga.html)
в оригинале
This solution has the following drawbacks:

The programming model is more complex. For example, a developer must design compensating transactions that explicitly undo changes made earlier in a saga.

There are also the following issues to address:

In order to be reliable, a service must atomically update its database and publish a message/event. It cannot use the traditional mechanism of a distributed transaction that spans the database and the message broker. Instead, it must use one of the patterns listed below.

это называется так сейчас —

простота обеспечения целостности данных

и

и наломают дров со стейтом куда меньше чем если сделают сагу для роллбека

обычную реляционку не осилили, зато более сложная сага им упростит жизнь!

Chris Richardson:
Summary: Sagas lack isolation — they are ACD rather than ACID.
You have to use countermeasures to enforce isolation at the application level.

Оба подхода имеют свои нюансы на самом деле. На моем опыте в микросервисах смоделированных по DDD optimistic locking хватает в преимущественном количестве сценариев обновления данных(они ложатся на сценарии работы с одним сервисом) без необходимости использования транзакций СУБД. Если операция затрагивает один сервис — все что нужно optimistic locking + атомарная запись. В рамках бизнесс логики скорее всего можно вообще будет обойтись без pessimistic локов и иметь состояние без конфликтов. В абсолютном меньшинстве необходимость использования саг для распределенных систем.

Например: давайте представим, что мы разрабатываем интернет магазин, где у клиента есть кредитный лимит. Приложение должно гарантировать, что новый заказ не превышает кредитный лимит клиента. Так как Заказы и Клиенты — различные базы данных, то приложение не может использовать локальные ACID транзакции.

Надо любой broker, что поддерживает неконкуретную обработку событий по partition key и упорядоченность(например kafka) и любое хранилище с возможностью иметь strong consistency на чтение(например mongo).

Дальше вопрос дизайна 2-3-4 ивентов, что будут идти один за другим и там, где конкуренция использовать нужный топик с верным partition key(например проверка кредитного лимита в рамках User service, user topic — partition key : userId, куда отправит событие WithdrawCredit OrderService) это будет гарантировать, что лимит не уйдет ниже 0.
Если кредита не хватает — шлется событие вернуть товар на склад (за счет того, что обработка неконкуретная по stock Id его заберет следующий, кто запросил этот товар).

В случае РСУБД надо будет лочить аккаунт юзера до конца операции с момента чтения(lock for update), либо использовать optimistic locking с транзакционным обновлением двух таблиц(Products, Account).

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

Это не призыв использовать саги, микросервисы как silver bullet.
Надо учитывать общие факторы насколько то или инное решение лучше подходит под конкретные задачи и условия. Ни оно из них не есть априори простым, но правильный подбор инструментария под конкретную задачу может сильно упростить жизнь.

То что вы пишите чисто литературное восприятие проблемы — было бы интересно если бы вы могли привести практические аргументы, проблематику реальных ситуаций и систем.

Summary: Sagas lack isolation — they are ACD rather than ACID.

главное, что данные консистентные и согласованные так же как и с ACID совместимыми системами.

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

А о том что они более сложные и не надёжные пишет для меня более авторитетный Крис Ричардсон. Там в обсуждении есть.

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

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

Вынесите базу в отдельный актор. Вообще не нужна будет защита, когда доступ в один поток. И может начать работать раз в 10 быстрее.

Что за дичь?
Если все запросы начнут работать в одном потоке то это узкое горлышко на порядки запросто ухудшит быстродействие.
основные бд даже выполнение запросов паралелят

А тут один жирный запрос и все простые стоять будут

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

1) Если все записи идут из одного потока, в базе не нужно блокирование (read uncommitted isolation level). Это уже ускорит работу самой БД.
2) Если все доступы идут из одного потока, эффективнее работает кеш ОС (и HDD).
3) Нет проблемы синхронизации кешей разных потоков при записи — там был еще один источник тормозов и сложности.
4) Можно написать кастомное кеширование данных в адаптере, которое будет максимально отвечать паттернам использования данных приложением.

основные бд даже выполнение запросов паралелят

Тут тоже вариант запускать чтения в несколько потоков (запись — в один). Если да — нужно смотреть, будут ли проблемы с read uncommitted. Но по-идее, большинство чтений приложения должно быть из оперативки (для этого кеш руками и делают). А что не из кеша — можно вставить в очередь между записями и обработать в том же потоке.

А тут один жирный запрос и все простые стоять будут

Если это аналитика с выборками или статистикой — проанализировать, повлияет ли на нее read uncommitted. Скорее всего — нет. Если да — можно подумать о том, чтобы гонять выборки на бекапной машине, а не грузить основной прод.

Если все записи идут из одного потока, в базе не нужно блокирование

если все записи идут из одного потока — то они уже заблокированы ожиданием окончания предыущей записи.

при этом мы лишаемся возможности БД — сделать одновременные записи для независимых данных.
Заблокировали похлеще SERIALIZABLE по умолчанию.

Если все доступы идут из одного потока, эффективнее работает кеш ОС (и HDD).

у БД — свои системы кеширования. еще и с учетом статистики.
в итоге на горячих данных — они рабоают эффективнее чем кеш ОС

Нет проблемы синхронизации кешей разных потоков при записи

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

Можно написать кастомное кеширование данных в адаптере

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

которое будет максимально отвечать паттернам использования данных приложением.

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

Тут тоже вариант запускать чтения в несколько потоков (запись — в один).

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

Если это аналитика с выборками или статистикой — проанализировать,

и в итоге написать собственную БД, а даже не адаптер-монстр.

если все записи идут из одного потока — то они уже заблокированы ожиданием окончания предыущей записи.

Записи всегда заблокированы ожиданием окончания предыдущей записи — так работает жесткий диск, и даже оперативка youtu.be/TFETtW86zAc?t=1163
А когда пытаются писать несколько потоков одновременно — все становится намного хуже.

при этом мы лишаемся возможности БД — сделать одновременные записи для независимых данных.

Они могут быть одновременными только если в системе несколько дисков, и таблица по ним размазана. При этом будет куча поисков и локов в оперативке (даже если операции не связаны) пока база убедится, что писать можно.
Вот вопрос — сколько в системе независимых дисков (на независимом железе), и насколько они тормозные (если не тормозные — то ботлнек будет в оперативке или в процессоре на локах) и насколько часто независимые записи. Если часто — может, подумать про шардинг или разделение таблиц в разные базы? Когда такая высокая нагрузка на одну, что она не справляется в однопоточном варианте)

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

БД делает универсальный кеш, а здесь — под конкретное приложение. Поэтом написать проще, и работать будет эффективнее.

Записи всегда заблокированы ожиданием окончания предыдущей записи —

неправда :) даже MySQL не блокирует :)

так работает жесткий диск,

он то так работает, да вот БД не так работают :)

А когда пытаются писать несколько потоков одновременно — все становится намного хуже.

да ну нах :) у меня сейчас даже сессии тупо хранятся в БД — вы мне предлагаете перевести в однопоток и ждать пока 1 сессия в БД обновится? при том что сейчас, учитывая что ключи сессий разные — они пишутся одновременно, даже с учетом только DMA

Они могут быть одновременными только если в системе несколько дисков, и таблица по ним размазана

да ну нафик. Я в MS-DOS писал через DMA одновременно, в однопоточной системе, а вы мне говорите что нынешние серверные средства хранения тупее чем PC XT?

БД делает универсальный кеш, а здесь — под конкретное приложение.

БД делает адаптивный кеш под горячие данные, на основе статистики работы с данными, которая у вас откуда взялась, для конкретного приложения, особенно на этапе проектирования?

Записи всегда заблокированы ожиданием окончания предыдущей записи —

неправда :) даже MySQL не блокирует :)

так работает жесткий диск,

он то так работает, да вот БД не так работают :)

:) Ну расскажите, как БД заставляет головку диска писать в несколько мест одновременно. Может, кто-то из разработчиков ядра Линукса почитает, и сделает прорыв по скорости работы файловой системы.

да ну нах :) у меня сейчас даже сессии тупо хранятся в БД — вы мне предлагаете перевести в однопоток и ждать пока 1 сессия в БД обновится?

А сколько на запись или чтение сессии уходит? 50 мс?

да ну нафик. Я в MS-DOS писал через DMA одновременно, в однопоточной системе, а вы мне говорите что нынешние серверные средства хранения тупее чем PC XT?

DMA на жесткий диск? Ну расскажите, как там головка перемещалась, чтобы писать одновременно в разные дорожки.

БД делает адаптивный кеш под горячие данные, на основе статистики работы с данными, которая у вас откуда взялась, для конкретного приложения, особенно на этапе проектирования?

1) Так как кеш самописный и независим от 95% кода проекта, его можно подправить или переделать в любой момент.
2) У БД статистика работы с полями, а у самописного кеша — с entities, даже когда одна сущность размазана по нескольким таблицам. В кеше лежат сущности целиком, и нет случаев «полузакешированных» данных. Также, команды, работающие над основным кодом, могут отследить, какие сценарии тормозят, и можно оптимизировать кеш конкретно под эти сценарии.

Ну расскажите, как БД заставляет головку диска писать в несколько мест одновременно

ей этого не требуется.
критерии для доступности данных — «когда запись завершена» — не имеют прямого ожидания головки диска, и это поведение настраивается.

Может, кто-то из разработчиков ядра Линукса почитает

ядро Линукса ничего не знает о том когда БД посчитает данные — записанными.

А сколько на запись или чтение сессии уходит? 50 мс?

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

DMA на жесткий диск? Ну расскажите, как там головка перемещалась

не следил :)
мне главное было что процессор разгружается для другой работы.

Так как кеш самописный и независим от 95% кода проекта, его можно подправить или переделать в любой момент.

да, среди вебремесленников такое же мнение нередко
свои велосипеды лучше казенных.

У БД статистика работы с полями, а у самописного кеша — с entities, даже когда одна сущность размазана по нескольким таблицам

это все есть в ORMaх. даже самых простых.
зачем писать — самописное?

В кеше лежат сущности целиком,

особенно с значением текущего остатка на складе :)

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

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

критерии для доступности данных — «когда запись завершена» — не имеют прямого ожидания головки диска, и это поведение настраивается.

Ну тогда тем более работа в один поток не будет тормозить))) Ведь и писать ничего не нужно)

0.1 мс

Тогда чего боитесь? Чтение/запись 10К сессий в секунду одним потоком.

зачем писать — самописное?

* Чтобы не зависеть от ORM или DB с их проблемами и недостатками, которые могут вылезти через годы работы или при росте бизнеса. Чтобы можно было оптимизнуть.
* Чтобы можно было воспроизвести события и отдебажить.
* Чтобы начать писать логику до того, как подняли всю модель в DB.
* Чтобы если через пол-года разработки обнаружилась лажа с выбранной DB или выбранной схемой — максимально безболезненно пересесть на другую.

особенно с значением текущего остатка на складе :)

Это тоже может там лежать — все действия с остатками проходят через DB adapter. Если нужно. И добавить такую функцию — пару часов кода, потому что работа с остатками — это вызовы нескольких конкретных функций интерфейса адаптера. Больше никто никак не может остаток изменить. И все изменения в одном потоке.

у меня одна только печаль, посмотреть бы на ваш проект, где вы примените все эти идеи :)

Ну, в эмбедеде DB не развиты. От железа и стека IP телефонии именно так защищался.

Тогда чего боитесь?

того что пользователей выстрояться в очередь только на обновление сессий.
а сейчас они читают данные — вообще параллельно. не ожидая когда прочтет читающий перед ними.
и пишут — так же. иначе бы на расчетах у нас ui колом бы становился, как вы то про головки HDD рассказываете.
расчеты сейчас конечно идут недолго, всего-то по минуте, две. будут и больше.
но пользователи получают информацию. а с однопотоком бы — ждали все.

Чтобы не зависеть от ORM

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

Чтобы можно было воспроизвести события и отдебажить.

их и сейчас и воспроизводят, и дебажат

Чтобы начать писать логику до того, как подняли всю модель в DB.

так бизнес логика то обычно — простая :)
главная с ней проблема — она «нелогичная», и изменяется в процессе работы системы, нередко со скоростью «семи пятниц на неделе»

Чтобы если через пол-года разработки обнаружилась лажа с выбранной DB

это какая, интересно :)
и каким местом выбирали эту DB, и главное кто тот гений, что выбирал и не знал об этой лаже :)
не, бывает конечно. обычно из-за стоимости лицензий — вынуждены менять.

максимально безболезненно пересесть на другую.

фик получится

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

Это тоже может там лежать — все действия с остатками проходят через DB adapter.

остатка не существует. это вычисляемое значение.
если адаптер такой умный что хранит это значение и пересчитывает когда изменяются влияющие на него данные — то он берет на себе типичные функции DB.

потому что работа с остатками — это вызовы нескольких конкретных функций интерфейса адаптер

а фильтр по остаткам больше величины X но меньше Y — кто будет реализовывать?

И все изменения в одном потоке.

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

Ну, в эмбедеде DB не развиты.

в эмбедеде не DB не развиты.
а постоянная и непредсказуемая смена доменных правил обработки информации.

поэтому когда-то и появился — SQL (ˈɛsˈkjuˈɛl; англ. structured query language — «язык структурированных запросов») — декларативный язык программирования, применяемый для создания, модификации и управления данными

то есть
как вы блин заипали писать и переписывать код выборки данных
О, нате вам language и получайте свои данные как хочется!

а сейчас они читают данные — вообще параллельно. не ожидая когда прочтет читающий перед ними.
и пишут — так же. иначе бы на расчетах у нас ui колом бы становился, как вы то про головки HDD рассказываете.

Значит, база под капотом перемешавает запросы от приложения и расчеты) Для расчетов sigle writer / multiple readers или расчеты на реплике.

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

Да, так как велосипед маленький по сравнению с остальным проектом, то саппорт дешевый и быстрый. А вот добиться от производителя базы саппорт — ну, сами знаете, наверное.

их и сейчас и воспроизводят, и дебажат

Если хорошо воспроизводится. А вот тут как раз жаловались, что остаток −1 не воспроизводится. В таком случае надо ставить на ночь replay событий с заглушкой вместо базы, а утром — смотреть, где сассертило. В идеальном мире, когда все события на запись сохраняются.

так бизнес логика то обычно — простая :)
главная с ней проблема — она «нелогичная», и изменяется в процессе работы системы, нередко со скоростью «семи пятниц на неделе»

Может, у Вас — простая. В энтерпрайзах работают сотни человек по куче лет. Даже вон в Хромиуме 10М строк кода, большая часть — бизнес-логика нескольких сабдоменов.

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

это какая, интересно :)
и каким местом выбирали эту DB, и главное кто тот гений, что выбирал и не знал об этой лаже :)

На старте проекта могли не знать части требований или амбиций по масштабированию, или еще чего угодно. Или новая хотелка, которая не ложится на старую модель, но ложится на NoSQL. Есть адаптер — можно попробовать держать две базы под одним адаптером.

остатка не существует. это вычисляемое значение.
если адаптер такой умный что хранит это значение и пересчитывает когда изменяются влияющие на него данные — то он берет на себе типичные функции DB.

Если Вы говорите «остаток» и я говорю «остаток» и на полке лежит остаток — то это как раз доменный термин, и он очень даже существует, и все им пользуются. А то, что конкретно в Вашей реализации его нет, или он вычислимый — это как раз об отделении базы от домена. В домене остаток есть, в базе — нет. Адаптер — берет на себя функции базы (или Repository в DDD) и скрывает от доменной логики что там под капотом. То есть — он имплементит базу, работающую с доменными объектами («остатком» в нашем случае) независимо от того, является ли «остаток» вычислимым в используемой DB.

а фильтр по остаткам больше величины X но меньше Y — кто будет реализовывать?

В Specification добавляются поля больше/меньше, а в адаптер — код, преобразующий эти поля в параметры SQL запроса.

а постоянная и непредсказуемая смена доменных правил обработки информации.

Там подходит не обработка информации, а конечные автоматы. Вот на калькуляторе нажали «=» и он показал «42». Потому что где-то когда-то у него выставилось состояние, которое на нажатие «=» показывает «42». А в другом состоянии он «0» покажет.

Доменные правила — да, на последнем проекте были следующие:
1) У нас есть звонок от инициатора адресату. Требование: если звонок был на удержании, и пользователь положил трубку — перезвонить пользователю. И тут меняются понятия «инициатор», «адресат», «жизненный цикл звонка». И весь код, на них опирающийся.
2) Работали с радиотелефонами. Но они не продаются. Нужно в то же приложение влепить поддержку аналоговых проводных телефонов (по дороге сделав железку, которая умеет с ними работать).
3) Работали с одним USB устройством, обслуживающим несколько телефонов. Но пользователи могут захотеть в офис поставить больше аппаратов, чем поддерживает железка. Давайте мы будем уметь работать с несколькими USB устройствами через USB хаб.

Значит, база под капотом перемешавает запросы от приложения и расчеты)

так приложение и является инициатором расчетов.
и контролирует их.

Для расчетов sigle writer / multiple readers или расчеты на реплике.

ну да. так в старину и делали скажем для 1С у которой сплошь пессимистические блокировки в духе — «пишет только один, заблокировав все что можно, про запас»- делали копию, считали, «пару часов», копировали назад. или бухгалтера держали два экземпляра открытыми, в одном — смотрели остатки на момент последнего расчета, в другом вбивали новые данные.
(потому в больших проектах вокруг БД 1Сной появлились АРМы и на FoxPro, и на Java — потому что БД то умеет, но от 1Сного программиста все попрятали, за «адаптером» — целостность данных важнее)

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

Да, так как велосипед маленький по сравнению с остальным проектом

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

А вот тут как раз жаловались, что остаток —1 не воспроизводится

на стековерфлов на что только не жалуются.

В энтерпрайзах работают сотни человек по куче лет. Даже вон в Хромиуме 10М строк кода

хромиум не относится к «кровавому энтерпрайзу»

Или новая хотелка, которая не ложится на старую модель, но ложится на NoSQL.

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

Если Вы говорите «остаток» и я говорю «остаток» и на полке лежит остаток

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

В домене остаток есть, в базе — нет

остаток — не сущность, а количественная характеристика. и на практике получение количественной характеристики может вызывать немало головняка. и быть в топе проблем.

в теории да, чего там, на диаграмке дорисовал атрибут у объекта, и все готово, «прекрасная работа господин архитектор!»

Адаптер — берет на себя функции базы

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

и скрывает от доменной логики что там под капотом.

в любом коде будет какая-то процедура-функция которая вернет число — остаток товара.

но тогда непонято чем «скрывает» отличается от какого нить
db.runSQL("SELECT amount FROM ...")

db.runSQL — тоже ж скрывает что там база делает и даже какая, потому что диалектами обзавелись кажется все. Не, у Redis вроде еще нет rQL

ну ок, написали адаптер
class Adapter {
.... getAmount(...) {
return db.runSQL("SELECT amount FROM ...«)
}

это мы — скрыли по настоящему или понарошку?

ну ок, давайте в доменный объект засунем метод

class Goods {
.... getAmount(...) {
return db.getAmount(this)

теперь то мы по настоящему скрыли?
или еще слоев надо добавить?

В Specification добавляются поля больше/меньше, а в адаптер — код, преобразующий эти поля в параметры SQL запроса.

так этого добра полно уже
JPA Criteria например

и реализация JPA — совсем не тоненькая прослойка.

Там подходит не обработка информации, а конечные автоматы.

насколько я помню все состояние включенного компьютера можно представить в терминах конечного автомата.
смысл только в этом — какой?

на калькуляторе нажали «=» и он показал «42».

а кто отличает 42 кг от 42 м?
и кто запрещает сложить на калькуляторе эти 42

Доменные правила

в которых я не вижу главного что есть у меня в домене
истории

вы описали ситуации — наращивания, изменения функционала
а я описал выборки которые должны работать по истории, и на момент начала записи этой истории эти выборки — неизвестны.
а как появятся — обязаны работать. и с приемлимой скоростью.
а оптимизация — это только в докладах — посмотрели планы запросов, индексов понавесили, и все хорошо.
в действительности — абстракции потекут.
и вся красота
city.store.goods.get(’iPhone 12 Pro’).getAmount() тоже.
не замечали как фильтры товаров тормозят нередко?
вот потому тормозят — правильное ООП там. и лечат его обычно уже не сменой БД, потому что не поможет. а прикручиванием Elasticsearch
Потому что архитектура — это «решения, изменить которые считается сложным». ... необратимость (irreversibility) является главной причиной сложности. Он видел в гибких методологиях, применяемых в производстве и разработке ПО, сдвиг в борьбе со сложностью путем уменьшения необратимости, в противоположность общепринятым принципам борьбы со сложностью. Мне кажется, что одной из главных задач архитектора является удаление архитектуры путем устранения необратимости в дизайне ПО.
(Фаулер — Кому нужен архитектор? sergeyteplyakov.blogspot.com/2013/11/blog-post.html)
а жирные модели — это очень жесткая связанность.

это я еще не коснулся момента когда сами правила становятся привязаны к моменту времени
остатки до Х считаем так
а после Х — вот сяк
историю — не трогать, ее трактовка может измениться в будущем!
и что будем делать с нашими жирными объектами, в которые мы засунули такие характеристики?
правильно, делегировать их заполение сервису, адаптеру, репозиторию или еще какому EntityManagerу.
ну как при anemic, изначально пришлось бы :)
и вот такой дрейф, от rich на старте, до похудения доменных моделей в процессе эволюции я наблюдал много раз. и делался он исходя из практических соображений — скорости разработки и скорости выполения операций над — сырыми данными (которые под капотом — всегда). потому что rich — это сразу тебе SELECT N+1. и выстраивание в один поток только ухудшит ситуацию.
конечно за годы развития ORM появились и lazy возможности, и возможности указания prefetch правил. но ваш адаптер по описанию — еще круче, он умеет держать объекты в памяти в актуальном состоянии! делают и так, встречал, в специфических случаях
но делают и наоборот совсем — нафик все эти тонны кода, и всю логику в ХП на сторону БД — крайний случай помните, в LingvoLeo случился :)

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

но тогда непонято чем «скрывает» отличается от какого нить
db.runSQL("SELECT amount FROM ...«)

Здесь основной код приложения зависит от схемы базы.
goods_repository.GetAmount() полностью скрывает базу и ее схему. Соответственно, для изменения схемы не нужно будет перелопачивать весь код приложения, чтобы понять, где он завязан на старую схему.
Goods::GetAmount() смешивает функциональность репозитория (фабрики) и класса самого объекта. Нехорошо, но если по всему проекту так везде делается, то хоть понятно, откуда брать данные.

насколько я помню все состояние включенного компьютера можно представить в терминах конечного автомата.
смысл только в этом — какой?

Смысл в том, что в функциональной парадигме калькулятор не сделаешь — нажатие «=» никак нельзя превратить в «42» если не хранить состояние. То есть, у нас в калькуляторе не только обработка, но и накопление информации.

жирные модели — это очень жесткая связанность

Связность внутри модели домена, но она может быть отвязана от базы. В результате как раз базу можно заменить. Если подозреваешь, где упадешь — подстели соломку.

ну как при anemic, изначально пришлось бы :)

Так тут все супер! Мы разбили сложность на две части: кривые правила создания/заполнения объекта и прямые правила его работы. Фабрики для этого и придуманы.

ORM — наше все. Он за тебя делает все транзакции, и если люди не работали с чистым t-sql, то для них все эти понятия уже «под капотом», о которых большинство никогда не задумываются.

то для них все эти понятия уже «под капотом»,

при этом для меня отличие джуна и остальных выше как раз в том, что те кто выше — обязаны иметь представление что там под капотом у инструментов что они используют.
иметь представление — это не быть экспертом, это
знать 20% которое используется в 80% случаев.
знать 20% — это избегать грубейших ошибок, и принимать сносные, приемлимые решения (не лучшие)
не знаешь этих 20% — джун, таскозакрыватель, и пофик сколько там у тебя стажа и какая зарплата.

я и сам и близко не DBAщик.
но что там знать то, если понимешь что такое
Семафо́р (англ. semaphore) — примитив синхронизации работы процессов и потоков, в основе которого лежит счётчик, над которым можно производить две атомарные операции
и Мью́текс (англ. mutex, от mutual exclusion — «взаимное исключение») — примитив синхронизации, ...

своим джунам например я всего один линк даю, на докладик на ютьюбе, на 40 минут, от — рубиста о Postgrtess. он там на пальцах и банальных примерах показывает все «огромные количества» уровней изоляций и блокировок.
азбука ж. которой с головой будет хватать для обычных 80% кейсов, обычной такой работы «крудошлепов».

phpистам да, еще как-то простительно, привычка к однопоточному выполнению сказывается.
но джависту и дотнетчику — что там может быть непонятно, в этой азбуке?
не понимаю.

Так вопрос именно в том, когда человек начал работать. Условно 10+ лет назад почти любому программисту приходилось писать или как минимум читать и править кучерявые хранимки. Так же как и обеспечивать мультипоточность — в тех же десктоп приложениях.
А сейчас в вебе однопоточные запросы + ORM. И кстати, я считаю абсолютно правильным подход, когда многопоточность по максимуму избегается. Потому что это всегда проблемы, трудноуловимые баги, периодическая коррупция данных и т.д. Просто это приводит к тому, что люди работают много лет, но не понимают вообще что такое многопоточность и как с ней работать.

Так вопрос именно в том, когда человек начал работать.

нет, вопрос в том — с чем человек работает.
с реляционной БД? — ну так азбуку обязан знать.

А сейчас в вебе однопоточные запросы + ORM

в каком таком вебе однопоточные запросы?
в вебе как раз — одновременно приходит много запросов.

+ ORM

и что, даже расшифровать не может теперь букву R? в этой абревиатуре?

когда многопоточность по максимуму избегается

в вебе вы ее не можете избежать.
ну в том о котором я знаю.

мне один на собеседовании на честном глазу доказывал что MySQL однопоточный.
опытный, со стажем, не джун.

что у вас за однопоточный веб — расскажите, интересно :)

люди работают много лет, но не понимают

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

да и много лет работающий с чем-то — тоже может и не обязан. ну джун он тогда, и все. вечный.

мы о чем говорим — о том что работающий много лет уже в не в состоянии асилить доклад на 40 минут?

в каком таком вебе однопоточные запросы?
в вебе как раз — одновременно приходит много запросов.

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

Я имею в виду, что каждый запрос выполняется в отдельном контексте

ну это естественно — «один запрос, один поток» :)

но система то — многопользовательская :)

поэтому можно написать рабочее веб приложение или апишку ни разу не создав нескольких потоков

но их создаст веб сервер или иной менеджер потоков(процессов, fiber’ов) :)

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

и не решая задачи их синхронизации и доступа к данным.

ну тогда и будут — отрицательные остатки и балансы :)

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

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

но если и десктопное приложение работало с — данными требующими монопольного захвата — то тоже самое.

ну тогда и будут — отрицательные остатки и балансы :)

Так я о том же :)
Что созданные абстракции в виде ORM и HTTP запросы входящие отдельными потоками с отдельными контекстами скрывают под капотом детали, которые многие в итоге не знают, потому что уже выросло поколение программистов (в основном в вебе), которые условно никогда не писали SQL транзакций и никогда руками не создавали несколько потоков и все что относится к их синхронизации.
Вроде бы эти инструменты и делают нашу жизнь легче, но тот кто не знает что там под капотом будет каждый раз с удивлением вылавливать всякие DBConcurrencyException.

Принято, посмотрю на Сагу под таким неожиданным углом — как дуракозащищенное архитектурное решение

Оно то да, но потом смотришь код, который с одного аккаунта должен перевести на другой деньги, item какой-то и т.д. (естественно не уйдя в минус + могут быть какие-то ещё доп.проверки).

И спрашиваешь, так а если клиент «хакер» и дёрнет endpoint в 100 потоков одновременно, всё ли норм будет?

«Конечно, у нас же транзакция, ёпт».
А потом балансы не сходятся (транзакция необходимое, но недостаточное условие).

та даже не хакер
просто больше одной вкладки открыто.

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

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

Незнаю що там у вас, але наприклад в Спрінгу може бути проблема з викликом транзакційних методів всередині інших транзакційних методів. Такі викликаємі методи мають знаходитись не в тому ж класі, з якого вони викликаються або ж викликатись через self-посилання на клас. Інакше поведінка може бути не така як заплановано. Також транзакційні методи мають бути публічними.

Хм. Написать что ли статью как я переводил проект с монолита на микросервисы, а никто из пользователей не пожаловался? Надо будет сделать запрос, не нарушу ли я этим NDA.

Перед тем как что-то писать, стоит задуматься — скажу ли я что-то новое?
100% этой информации есть в КАЖДОЙ статье касательно микросервисов. Хочется выделиться — добавьте больше информации о личном опыте использования, интересных кейсах, с которыми столкнулись. Иначе это больше похоже на рерайт статей из интернетика для студенческой конференции.

Підписатись на коментарі