Комментарии

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

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

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

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

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

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

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

Я исхожу из того, что код домена, написанный по DDD должен быть в целом понятен бизнесу (англоговорящему). И где-то в коде new Customer($name, $address) будет более понятно при таком подходе, чем CustomerFactory::create($name, $address). Хотя в принципе непринципиально. Можно и фабричным методом/классом, особенно в форме Customer::registerNewCustomer(($name, $address). Но вот программные зависимости, а не значения свойств сущности в конструкторе класса сущности, по-моему, зло, которого не должно быть независимо от того Doctrine это или нет. Для меня это говорит о плохой проработке модели, или о выборе непоходящего для DDD инструментария, типа использования в качестве сущности наследника какого-нибудь ACtiveRecord

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

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

То есть инжектить сторонние зависимости через сигнатуру метода сущности? Тогда остаётся вопрос, в какой момент остановиться и не отработать весь процесс приложения в этом методе сущности)

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

Остаются бизнес-сервисы, сервисы предметной области. Тут подход другой: мы моделируем сущность, она имеет жизненный цикл и создаётся, конструируется только один раз. То есть ее конструктор должен вызываться только один раз. Если про rest-like веб API говорить, то где-то в обработчике соответствующего POST метода. Если про UI, то где-то в обработчик кнопок new/create/etc.

Используемый ORM/ODM/… или даже язык в целом, может не допускать такой сценарий и придётся использовать какой-то именованный конструктор/фабричный метод/фабрику, но вот семантика должна сохраниться, то есть инжектить сервисы через конструктор даже под их капотом всё равно нельзя, по-моему. У класса сущности должна быть одна ответственность — моделировать сущность предметной области. Если и надо что-то инжектить в сущность, то из-за эфемерной природы программных сервисов (их в базу не сохранишь), то через double dispatch

Вот это мне не удаётся хорошо обосновать. Стараюсь через Clean Architecture, но с сомнительным успехом. Еще через глобальное состояние и «чистоту» эффектов, но через это по-видимому я вообще только себе могу что-то доказать. В материалах по DDD разве есть что-то про это? По-моему нет.

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

DDD роли бизнес-аналитика и архитектора не исключает. Более того, субъективно, их функции становятся более важными. Бизнес-аналитик же по определению должен быть экспертом предметной области. Или нет? Да и архитектуру кто-то должен определять. Например, «достоин» ли какой-то контекст, агрегат или даже сущность выноса в отдельный сервис или нет.

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

Да, есть такое. Поэтому мы и пытались сделать лаг репликации минимальным.

Репликационный слот накладывает ограничение на перезапись wal. Т.е. пока данные из слота не прочитаны wal будет расти и при высокой нагрузке может очень быстро съесть все отведенное место на диске, с дальше сервер упадёт с ошибкой.

Создает, но меньшую. Намного меньшую.

А репликационный слот не создает нагрузки?

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

Нагрузка не может не увеличится, вы же как минимум выполняете операцию чтения WAL. Плюс сам инструментарий.

Познавательно для желающих реализовать репликацию данных. Сам писал собственный тул для реплицирования из SQLServer в PostgreSQL и Kafka на основе вычитывания данных из SQLServer Snapshot и последующим автоматическим переключением на живую SQLServer базу и считыванием изменений из CDC (LSN является ориентиром). Очень много подводных камней. Сейчас улучшаю перформанс первоначальной загрузки из snapshot и тесты показывают, что в разы вырастает скорость если считываю данные из snapshot в CSV, после через CopyIn в PostgreSQL с временным удалением индексов и primary ключей в PostgreSQL.

Решения для работы с распределёнными источниками

БД-источник может быть шардированной, как, например, Tarantool. Каждый из инструментов работает с такими БД по-разному.

— Debezium Embedded. Масштабирование выполняется по шардам и вручную, оффсеты хранятся в приёмнике для каждого шарда.
— Debezium Server. Масштабирование выполняется по шардам с помощью Kubernetes. Оффсеты хранят в файле, Kafka, Redis, приемнике для каждого шарда.
— Kafka-connect. Масштабирование выполняется по шардам с помощью тасков Kafka-connect — для каждого ReplicaSet запускается отдельный таск, который будет считывать данные. Оффсеты для каждого шарда хранятся в Kafka.

Главное из нашего опыта

— Зачастую к репликации высокие требования. Нам были важны скорость, отказоустойчивость, отсутствие дополнительной нагрузки. Исходя из этих требований мы выбрали механизм Change Data Capture, который удовлетворял всем основным критериям.
— Инструмент надо выбирать с учётом стека конечных пользователей. Наши заказчики часто работают с Java, поэтому, чтобы обеспечить совместимость решения, в качестве основы стека мы выбрали Java и Debezium.
— Монолитные приложения не всегда хороши. Debezium Embedded было сложно масштабировать и конфигурировать, поэтому мы перешли на Debezium Server. Это универсальное не монолитное решение, которое позволяет добавлять свои коннекторы и масштабироваться с помощью Kubernetes.
— Ошибки при создании инструмента для репликации неизбежны. Мы столкнулись с рядом проблем: высокий лаг, низкая отказоустойчивость, сложная архитектура. Каждый из недостатков нам пришлось устранять отдельно. Но тщательная доработка помогла нам получить инструмент, с помощью которого можно переливать данные из PostgreSQL в Tarantool с низким лагом репликации и сохранением консистентности.

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

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

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