Комментарии

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

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

Остаются бизнес-сервисы, сервисы предметной области. Тут подход другой: мы моделируем сущность, она имеет жизненный цикл и создаётся, конструируется только один раз. То есть ее конструктор должен вызываться только один раз. Если про 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 с низким лагом репликации и сохранением консистентности.

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

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

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

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

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

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

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

Изъяны в данных могут привести к различным результатам. Например, клиенту Skyscanner Джеймсу Ллойду на пути из Крайстчёрча (Новая Зеландия) в Лондон предложили подождать в Банкоке 413 786 часов, или 47 лет. Эта история стала виральной благодаря чувству юмора SMM Skyscanner по имени Джен, ответившей на вопрос Джеймса о том, что он может делать все эти годы.

Использование ошибочных данных может приводить к трагическим событиям, особенно в медицинской сфере. Дэвид Лошин в статье The Practitioner’s Guide to Data Quality Improvement упоминает случай 2003 года с Джесикой Сантиллан, погибшей из-за некачественной сердечно-лёгочной трансплантации. Хирург использовал органы донора с несовместимой группой крови. Ошибочная информация о группе крови вызвала хирургические осложнения, приведшие к смерти.

Низкокачественные данные также могут препятствовать и замедлять интеграцию бизнес-аналитики и прогностической аналитики на основе ML. Руководители компаний США, участвовавшие в опросе Data trust pulse, проведённом PricewaterhouseCoopers, указали, что ненадёжные данные — одно из препятствий к монетизации данных. «Во многих из исторических данных компании, собиравшихся хаотически, могут отсутствовать нужные подробности и точность, необходимые для работы с ИИ и другими технологиями автоматизации», — говорится в результатах опроса.

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

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

Изъяны в данных могут привести к различным результатам. Например, клиенту Skyscanner Джеймсу Ллойду на пути из Крайстчёрча (Новая Зеландия) в Лондон предложили подождать в Банкоке 413 786 часов, или 47 лет. Эта история стала виральной благодаря чувству юмора SMM Skyscanner по имени Джен, ответившей на вопрос Джеймса о том, что он может делать все эти годы.

Использование ошибочных данных может приводить к трагическим событиям, особенно в медицинской сфере. Дэвид Лошин в статье The Practitioner’s Guide to Data Quality Improvement упоминает случай 2003 года с Джесикой Сантиллан, погибшей из-за некачественной сердечно-лёгочной трансплантации. Хирург использовал органы донора с несовместимой группой крови. Ошибочная информация о группе крови вызвала хирургические осложнения, приведшие к смерти.

Низкокачественные данные также могут препятствовать и замедлять интеграцию бизнес-аналитики и прогностической аналитики на основе ML. Руководители компаний США, участвовавшие в опросе Data trust pulse, проведённом PricewaterhouseCoopers, указали, что ненадёжные данные — одно из препятствий к монетизации данных. «Во многих из исторических данных компании, собиравшихся хаотически, могут отсутствовать нужные подробности и точность, необходимые для работы с ИИ и другими технологиями автоматизации», — говорится в результатах опроса.

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

Думаю Вам следует тщательно оценить Аврору, прежде чем рассматривать ее. Запустите экземпляр и настройте тестовый экземпляр вашего приложения и базы данных. Создайте как можно большую нагрузку. Я делал это в своей прошлой компании и обнаружил, что, несмотря на заявления Amazon о высокой производительности, Aurora потерпела сокрушительное поражение. На два порядка медленнее, чем RDS. У нашего приложения был высокий уровень трафика записи.

Наш вывод: если у вас есть вторичные индексы и высокий трафик записи, Aurora не подходит. Могу поспорить, что это хорошо для трафика только для чтения.

(Редактировать: тестирование, которое я описываю, было проведено в первом квартале 2017 года. Как и в случае с большинством сервисов AWS, я ожидаю, что Aurora со временем улучшится. У Amazon есть четкая стратегия: « Выпускать идеи на 70%, а затем повторять ». Отсюда мы должны сделать вывод, что новый продукт AWS достоин тестирования, но, вероятно, не готов к производству в течение как минимум нескольких лет после его представления).

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

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

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

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

— Amazon RDS Аврора
— Amazon RDS MySQL
— MySQL в экземплярах EC2

Я считаю, что Amazon Aurora позиционируется как лучшая альтернатива, однако после некоторых исследований кажется, что люди ее не используют. Есть ли в этом проблема?

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

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

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

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

— соединение выбранных элементов структуры и поведения во всё более крупные системы;

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

Наиболее понятным, на мой взгляд, кажется определение, которое объединит эти два понятия:

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

Проще говоря, если мы решили использовать HEAD-FIRST подход (сначала думай, потом делай), то без проработки архитектуры нам не обойтись. Да и в ситуации, когда мы сначала всё сделали, а потом начали думать – к вопросу архитектуры мы тоже придем, только теперь с большим объемом кода, который надо переписывать.

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

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

Во-первых, микросервисная архитектура является подтипом сервис-ориентированной архитектуры.

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

Итак, монолит – это иерархическая архитектура, т.е каждый слой приложения отвечает за свою часть функционала, например: работа с базой, логирование, интерфейс (простота E2E тестирования, простота развертки). Глубоко разбирать монолиты не будем. Отметим, что есть несколько видов наиболее популярных шаблонов монолита:

Model-View-Controller (MVC, «Модель-Представление-Контроллер», «Модель-Вид-Контроллер») — схема разделения данных приложения и управляющей логики на три отдельных компонента: модель, представление и контроллер — таким образом, что модификация каждого компонента может осуществляться независимо.

— Модель (Model) предоставляет данные и реагирует на команды контроллера, изменяя своё состояние.

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

— Контроллер (Controller) интерпретирует действия пользователя, оповещая модель о необходимости изменений.

Model-View-Presenter (MVP) — шаблон проектирования, производный от MVC, который используется в основном для построения пользовательского интерфейса.

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

Model-View-ViewModel (MVVM) — шаблон проектирования архитектуры приложения, представленный в 2005 году Джоном Госсманом (John Gossman) как модификация шаблона Presentation Model. Ориентирован на современные платформы разработки, такие как Windows Presentation Foundation, Silverlight от компании Microsoft, ZK framework.

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

Про масштабируемость:

— Монолит — масштабируется не рационально(поднимаем всё) + не всегда возможно, если монолит изначально не писался с учетом масштабируемости

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

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

Лайфхак: никто не догадается о том, что монолит, это монолит, если не допускать людей к кодовой базе! :)