tgoop.com/microservices_arch/467
Last Update:
/// продолжение
В чем тут потенциальные проблемы?
- Двойные усилия, – параллельно из двух сервисов вычищается ненужный код
- Цена ошибки, – если мы допустили ошибку в определении места того или иного понятия, то в рамках единой кодовой базы мы просто перебросим код средствами IDE, если же это разные сервисы, то нужно будет перекидывать логику из одного сервиса в другой, физически из одного репозитория в другой. Если вспомнить, что сервисы не живут в изоляции, то нужно будет перенести и тестовые сценарии, а возможно и изменить какие-то внешние интерфейсы. Это очень дорого.
- Миграция данных, – опять же, следствие физического разграничения, – нужно будет не только бизнес-логику передать в другой сервис, но и физически мигрировать данные, а это могут быть в принципе даже совершенно разные базы данных (PG и Mongo, например).
Вывод
Несмотря на то, что изображение действительно может вызвать неоднозначное толкование, процесс на нем показан корректный с точки зрения иллюстрации того, каким образом происходит разрыв зависимостей на уровне предметной области, а именно, – устранение множественных, несовместимых на уровне моделей/контекстов, ответственностей и атрибутов. Несовместимых здесь означает, что есть одна сущность, например Contract, используется в двух моделях и в каждой из моделей у этой сущности есть атрибуты или поведение, которые не определены в этой модели или имеют собственное определение в каждой из моделей. Последнее означает, что каждая модель использует атрибут по-своему в своем контексте и изменения в одной модели могут привести (и часто приводят) к некорректному поведению в другой модели.
Надеюсь, что после этого пояснения станет немного понятнее, спасибо за внимание 🙂
PS: сама презентация: https://speakerdeck.com/hschwentner/domain-driven-transformation
BY Микросервисы / распределенные системы
Share with your friend now:
tgoop.com/microservices_arch/467