Шаблон уровня защиты от поврежденияAnti-Corruption Layer pattern

Между разными подсистемами с разной семантикой можно реализовать уровень оболочки или адаптера.Implement a façade or adapter layer between different subsystems that don't share the same semantics. Этот уровень будет преобразовывать запросы от одной подсистемы к другой.This layer translates requests that one subsystem makes to the other subsystem. Используйте этот шаблон, чтобы гарантировать, что схема приложения не ограничена зависимостями во внешних подсистемах.Use this pattern to ensure that an application's design is not limited by dependencies on outside subsystems. Впервые этот шаблон описал Эрик Эванс (Eric Evans) в книге Предметно-ориентированное проектирование.This pattern was first described by Eric Evans in Domain-Driven Design.

Контекст и проблемаContext and problem

Большинство приложений используют другие системы для некоторых данных или функций.Most applications rely on other systems for some data or functionality. Например, при миграции приложения прежних версий в новую систему по-прежнему могут потребоваться устаревшие ресурсы.For example, when a legacy application is migrated to a modern system, it may still need existing legacy resources. Новые компоненты должны вызвать устаревшую систему.New features must be able to call the legacy system. В частности, это относится к постепенным миграциям, где различные компоненты более крупных приложений со временем перемещаются в современные системы.This is especially true of gradual migrations, where different features of a larger application are moved to a modern system over time.

В устаревших системах часто появляются проблемы с качеством, такие как сложные схемы данных или устаревшие API.Often these legacy systems suffer from quality issues such as convoluted data schemas or obsolete APIs. Компоненты и технологии, используемые в устаревших системах, могут существенно отличаться от новых систем.The features and technologies used in legacy systems can vary widely from more modern systems. Для взаимодействия с устаревшей системой новому приложению может потребоваться поддержка устаревшей инфраструктуры, протоколов, моделей данных, API-интерфейсов или других компонентов, которые в противном случае вы не поместили бы в новое приложение.To interoperate with the legacy system, the new application may need to support outdated infrastructure, protocols, data models, APIs, or other features that you wouldn't otherwise put into a modern application.

Для обеспечения доступа между новыми и устаревшими системами в новой системе может потребоваться принудительно использовать по крайней мере некоторые API-интерфейсы или другую семантику устаревших систем.Maintaining access between new and legacy systems can force the new system to adhere to at least some of the legacy system's APIs or other semantics. Если в устаревших компонентах возникают проблемы с качеством, их поддержка может быть нецелесообразна в хорошо спроектированном современном приложении.When these legacy features have quality issues, supporting them "corrupts" what might otherwise be a cleanly designed modern application.

Аналогичные проблемы могут возникнуть в любой внешней системе, которую не контролирует ваша команда разработчиков, а не только в устаревших системах.Similar issues can arise with any external system that your development team doesn't control, not just legacy systems.

РешениеSolution

Изолируйте разные подсистемы, поместив между ними уровень защиты от повреждений.Isolate the different subsystems by placing an anti-corruption layer between them. Этот уровень преобразует обмен данными между двумя системами, за счет чего одна система не изменяется, а в другой сохраняется структура и технологический подход.This layer translates communications between the two systems, allowing one system to remain unchanged while the other can avoid compromising its design and technological approach.

Шаблон уровня защиты от повреждения

На приведенной выше схеме показано приложение с двумя подсистемами.The diagram above shows an application with two subsystems. Подсистема A вызывает подсистему B через уровень защиты от повреждений.Subsystem A calls to subsystem B through an anti-corruption layer. При обмене данными между подсистемой A и уровнем защиты от повреждений всегда используется модель данных и архитектура подсистемы A. Вызовы из уровня защиты от повреждений к подсистеме B соответствуют модели данных и методам этой подсистемы.Communication between subsystem A and the anti-corruption layer always uses the data model and architecture of subsystem A. Calls from the anti-corruption layer to subsystem B conform to that subsystem's data model or methods. Уровень защиты от повреждения содержит всю логику, необходимую для преобразования между двумя системами.The anti-corruption layer contains all of the logic necessary to translate between the two systems. Его можно реализовать как компонент в приложении или как независимую службу.The layer can be implemented as a component within the application or as an independent service.

Проблемы и рекомендацииIssues and considerations

  • Уровень защиты от повреждения может привести к задержкам в вызовах между системами.The anti-corruption layer may add latency to calls made between the two systems.
  • Уровень защиты от повреждения добавляет дополнительную службу, требующую управления и поддержки.The anti-corruption layer adds an additional service that must be managed and maintained.
  • Определите способ масштабирования уровня защиты от повреждения.Consider how your anti-corruption layer will scale.
  • Определите количество уровней защиты от повреждения.Consider whether you need more than one anti-corruption layer. Вам может потребоваться разделить функциональные возможности на несколько служб, использующих различные технологии и языки. Или же у вас могут быть другие причины для разделения уровня защиты от повреждения.You may want to decompose functionality into multiple services using different technologies or languages, or there may be other reasons to partition the anti-corruption layer.
  • Подумайте об управлении уровнем защиты от повреждения в контексте своих приложений и служб,Consider how the anti-corruption layer will be managed in relation with your other applications or services. а также о том, как он будет интегрироваться с процессами наблюдения, выпуска и конфигурации.How will it be integrated into your monitoring, release, and configuration processes?
  • Убедитесь в том, что транзакции и целостность данных сохраняются и их можно отслеживать.Make sure transaction and data consistency are maintained and can be monitored.
  • Определите объем задач для уровня защиты от повреждений: обработка всех данных, передаваемых между разными подсистемами, или только подмножества функций.Consider whether the anti-corruption layer needs to handle all communication between different subsystems, or just a subset of features.
  • Если уровень защиты от повреждений входит в стратегию переноса приложений, определите, будет ли он постоянным или его использование будет прекращено после переноса всех устаревших функциональных возможностей.If the anti-corruption layer is part of an application migration strategy, consider whether it will be permanent, or will be retired after all legacy functionality has been migrated.

Когда следует использовать этот шаблонWhen to use this pattern

Используйте этот шаблон в следующих случаях:Use this pattern when:

  • Планируется миграция в несколько этапов, но необходима поддержка интеграции между новыми и устаревшими системами.A migration is planned to happen over multiple stages, but integration between new and legacy systems needs to be maintained.
  • Семантика разных подсистем различна, но по-прежнему требуется их взаимодействие.Two or more subsystems have different semantics, but still need to communicate.

Этот шаблон неприменим в случае несущественных семантических различий между новыми и устаревшими системами.This pattern may not be suitable if there are no significant semantic differences between new and legacy systems.