【ITニュース解説】You May Need an Anti-Corruption Layer

システム開発において、外部システムからのデータを受け取る際、そのデータの形式が必ずしも理想的とは限らない。特に、レガシーシステムや変更が難しい外部APIからのデータは、データの型が曖昧であったり、必要な情報が欠けていたりすることがある。このような状況で、そのまま外部データの形式に依存したコードを書いてしまうと、アプリケーション全体に悪影響が及ぶ可能性がある。これが「腐敗」であり、それを防ぐのが「Anti-Corruption Layer（ACL）」だ。

具体例として、あるバックエンドサービスからのレスポンスを表すUserDTOインターフェースを考えてみる。

Copy
1interface UserDTO {
2  user_name?: string // optional... really
3  user_age?: string // API sends age as string
4  email_address?: string // legit or naw?
5  created_at?: number // a string date... meh
6}

この例では、全てのプロパティがオプショナル（?）であり、user_ageは文字列型、created_atは数値型（実際には日付文字列を表していると思われる）となっている。このような型定義に基づいてアプリケーションを構築すると、至る所でデータの存在チェックや型変換が必要になり、コードが複雑化し、保守性が低下する。

ACLは、このような問題を解決するために導入される。ACLは、外部システムから受け取ったデータ（この例ではUserDTO）を、アプリケーション内部で利用するデータ形式（Value Object: VO）に変換する役割を担う。VOは、アプリケーションのドメインロジックに最適化された型であり、必要なプロパティが必須であり、適切な型で定義されている。

ACLの実装は、オブジェクト指向プログラミング（OOP）と関数型プログラミング（FP）で異なるアプローチをとる。OOPでは、ACLは通常、クラスとして実装される。このクラスは、DTOをVOに変換するメソッドと、VOをDTOに変換するメソッドを提供する。DTOからVOへの変換は、データの検証や変換に失敗する可能性があるため、エラーハンドリングが必要となる。一方、VOからDTOへの変換は、通常、失敗することはない。

Copy
1class UserMapper { 
2  toDomain(dto: UserDTO) => Result<User, MappingError>
3  toDTO(user: User) => UserDTO
4}

FPでは、ACLは型と関数の組み合わせとして実装される。DTOとVOに対応する型を定義し、DTOからVOへの変換を行う関数と、VOからDTOへの変換を行う関数を定義する。DTOからVOへの変換関数は、Result型などを利用して、変換の成功または失敗を明示的に表現することが推奨される。

ACLを導入することで、アプリケーションは外部データの形式に依存せず、自身のドメインロジックに集中できる。また、外部データの形式が変更された場合でも、ACLの実装を変更するだけで、アプリケーション全体への影響を最小限に抑えることができる。

ACLの実装においては、以下の点に注意する必要がある。

• VOの定義: VOは、アプリケーションのドメインロジックに合致するように、慎重に定義する必要がある。
• エラーハンドリング: DTOからVOへの変換が失敗した場合のエラーハンドリングを適切に行う必要がある。
• データの検証: DTOからVOへの変換時に、データの検証を行うことで、不正なデータがアプリケーション内部に侵入するのを防ぐことができる。ZodやArkTypeといったライブラリを使用すると、より効率的にデータ検証を実装できる。
• 部分的なデータの許容: 外部APIから提供されるデータが不完全な場合、VOの型を安易にオプショナルにせず、Discriminated Unionsなどを活用して、データの状態を明確に表現することが重要になる。

ACLは、外部システムとの連携において、アプリケーションの品質を維持するための重要なパターンである。特に、変更が難しい外部APIを利用する場合や、レガシーシステムとの連携を行う場合には、ACLの導入を検討する価値がある。