アンチ・コロプション・レイヤー(ACL)は、統合時に外部システムの影響からアプリケーションの内部ドメインモデルを保護するために使用されるアーキテクチャパターンです。
目的: システムが他のシステムとやり取りするとき(例えば、古いソフトウェアやサードパーティのサービスからデータやビジネスロジックを受け継ぐ場合)、外部契約が変更されたり、歪みを含むことがあります。ACLは、ビジネスロジックと互換性のない変更から内部モデルを切り離すことを可能にします。
実装方法: 追加のコンポーネント—アダプターやファサード—を導入し、外部データ/インターフェースを内部オブジェクトに変換します。これには、サービス、マッパー、特別なDTOクラスが含まれる場合があります。
Pythonの例:
class ExternalOrder: def __init__(self, order_id, amount, created_at): self.order_id = order_id self.amount = amount self.created_at = created_at class InternalOrder: def __init__(self, id, total, timestamp): self.id = id self.total = total self.timestamp = timestamp class OrderAdapter: @staticmethod def from_external(external_order): return InternalOrder( id=external_order.order_id, total=external_order.amount, timestamp=external_order.created_at )
ここで、OrderAdapterは外部注文の構造の変更から内部システムを隔離します。
主な特徴:
POJO/DTOのマッパー層を単純に使用することで、完全なACL代わりとなることは可能ですか?
いいえ、単純なマッパーはビジネスロジックを保護せず、完全なアダプターとは言えません。ACLは、安全な統合を実現するための全体的なレイヤーであり、コマンド、イベント、ビジネスエラーのコンテキスト変換も含まれています。
ACLでは何レベルの変換が許容されますか?
完全な隔離を確保するために必要なだけのレベルです。通常は、構造の変換とビジネスロジックのマッピング(例えば、ステータス、エラーコード、アクセスポリシー)の少なくとも2つのレベルが必要です。
ACLにおける外部システムのエラーを適切に処理する方法は?
ACLは、外部エラーを内部の例外クラスやステータスコードに適応させる必要があります。外部システムのエラーをアプリケーション内に直接スローしてはいけません。