Дифференцируйте логику микросервиса по конфигурации или новой службе

Я согласен с Адрианом, это зависит от вашей ситуации.

Я думаю, что наиболее важным является сложность системы - она ​​играет решающую роль в тестировании, поддержке и развитии системы. (ЦЕЛОВАТЬ)

Так что я думаю, что лучший вариант - 2.

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

Это зависит. К вашему сведению, я знаю о Кафке, но не имею в этом опыта.

Для варианта 3: насколько развита ваша способность управлять различными экземплярами решения с разной конфигурацией? Сколько было бы экземпляров? Как бы вы могли наблюдать за здоровьем, поведением и производительностью всех экземпляров?

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

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

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

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

Обновление - вариант 2

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

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

Я думаю, что меня больше всего беспокоит тип результатов, которые производят услуги. Если (для всех трех вариантов) результатом процесса будет один и тот же тип (или объект домена), я, безусловно, предпочту Вариант 1.

Это согласуется с принципом «слабой связи, связного поведения», о котором Сэм Ньюман писал в своей статье книга.

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

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

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

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

Эта служба действительно будет зависеть от производителя, потому что она ему нужна как источник. Это невозможно обойти. То же самое в некоторой степени верно и для всех других вариантов. Но зависимость такова: потребитель зависит от производителя, а не наоборот!