はじめに:きれいなコードを書きたいのに…
エンジニアなら誰しも、「きれいで、読みやすくて、変更しやすいコード」を書きたいと思いますよね。 でも、現実のプロジェクト、特に歴史のある「レガシーシステム」と連携するとなると、話は一気に難しくなります。
- 「なんでこのカラム名、
status_flag_3なの…?(意味がわからない)」 - 「データがJSON文字列で入ってて、SQLで集計するのが地獄…」
- 「相手のシステムの仕様が変わったら、こっちのきれいなロジックまで書き直さなきゃいけない…」
こんな経験、ありませんか? せっかく自分たちが作っている新しいシステム(例えば、きれいな設計のDWH)が、古いシステムの「カオスな仕様(負債)」に染められていく…。
これを専門用語で「汚染(Corruption)」と呼びます。
この汚染から、自分たちの聖域(新しいシステム)を守るための強力な盾、それが今回紹介する「防腐層(Anti-Corruption Layer / ACL)」です。
防腐層(ACL)とは?:あなた専属の「超優秀な通訳さん」
防腐層(ACL)を一言で言うと、「古いシステムと新しいシステムの間に立つ、翻訳機兼ガードマン」です。
DDD(ドメイン駆動設計)という設計思想の用語ですが、考え方はとてもシンプルです。
イメージしてみよう
- 新しいシステム(あなた): きれいな日本語(最新の設計思想、明確な用語)を話したい。
- 古いレガシーシステム: 独自のクセが強い方言(カオスなデータ構造、昔の用語)を話す。
普通に会話(連携)しようとすると、あなたも古い方言に合わせなきゃいけなくなり、あなたのきれいな日本語がだんだん崩れていきます(汚染)。
ここに「超優秀な通訳さん(ACL)」を挟むとどうなるでしょう?
graph LR A[レガシーシステム] -- "「方言」で話す" --> B(通訳さん / ACL) B -- "「きれいな日本語」に翻訳" --> C[新しいシステム]
通訳さん(ACL)が、古い方言をその場で瞬時にきれいな日本語に翻訳してくれるので、あなたは古い方言を覚える必要も、それに染まる必要もありません。 常にきれいな日本語だけで、本来の仕事に集中できます。
これが、ACLの本質的な役割です。
具体例:MySQLからRedshift(DWH)へのデータ連携
前回の記事で紹介した、カオスなMySQLデータをRedshiftへ送る例で、ACLが何をしているのかを見てみましょう。
【入力】レガシーMySQLのカオスなデータ
type:'2'(システムのコード。誰も意味を知らない)price_data:'{"total": 5000, "discount": 200}'(JSON文字列)del_flg:'0'(有効データ)
【防腐層(ACL)の中の人】がやってくれること
- ゴミを捨てる(フィルタリング)
- 通訳さん:「おっと、
del_flg = '1'(削除済み)のデータは、新しいシステム(Redshift)には必要ないね。ここで捨てておこう」
- 通訳さん:「おっと、
- 意味を翻訳する(セマンティック変換)
- 通訳さん:「この
type = '2'っていうのは、ソースコードを読むと『法人定期』という意味か。よし、新しいシステムには'CORPORATE_SUBSCRIPTION'という分かりやすい名前に翻訳して伝えよう」
- 通訳さん:「この
- 型を整える(構造変換)
- 通訳さん:「JSON文字列のままだとRedshiftで計算しにくいな。パース(解析)して、
total_amountとdiscount_amountという数字のカラムに展開しておこう」
- 通訳さん:「JSON文字列のままだとRedshiftで計算しにくいな。パース(解析)して、
- 計算しておく(事前計算)
- 通訳さん:「正味の売上金額(Net Sales)は、分析でよく使うはずだ。ここで
5000 - 200 = 4800と計算して、net_sales_amountというカラムを作っておこう」
- 通訳さん:「正味の売上金額(Net Sales)は、分析でよく使うはずだ。ここで
【出力】Redshiftに入るクリーンなデータ
customer_type:'CORPORATE_SUBSCRIPTION'(明確!)total_amount:5000(数字!)net_sales_amount:4800(計算済み!)
Redshiftを使う分析者は、レガシーMySQLの複雑怪奇な仕様を1ミリも知らなくても、きれいなSQLで分析ができるようになります。
ACLの最大のメリット:将来の「リプレイス」に強くなる!
「通訳さん(ACL)を作るのは手間だし、コストがかかるんじゃない?」
確かにそうです。でも、ACLには初期コストを払う価値がある、最大のメリットがあります。
将来、「古いレガシーMySQLを、新しい最新のDBに置き換える(リプレイスする)」というプロジェクトが立ち上がったとします。
- ACLがない場合:
- Redshiftの中もレガシー仕様なので、MySQLが新しいDBに変わったら、Redshiftの中のデータモデルも、BIツールのSQLも、全て一から作り直しです(地獄です)。
- ACLがある場合:
- 通訳さん(ACL)の「入力側(MySQL用)」を「新しいDB用」に差し替えるだけです。
- ACLが「同じクリーンなデータ」をRedshiftに吐き出し続ける限り、RedshiftやBIツール側は、上流システムが変わったことに「気づきさえしません」。
これこそが、ACLが「将来への投資」と言われる理由です。システム間の依存を断ち切り、自分たちの聖域を安全に保つことができます。
まとめ:いつACLを使うべき?
防腐層(ACL)は強力な武器ですが、全ての連携で必要ではありません。
- 使うべき時:
- 連携相手のシステムのデータ構造や命名が、自分たちの設計思想と明らかにかけ離れている(カオスである)。
- 自分たちのシステムを、相手システムの変更から完全に隔離したい。
- 将来、相手システムのリプレイスが確実に予定されている。
- 使わなくて良い時(dbtなどを活用):
- 連携相手のシステムも比較的きれい。
- とにかくスピード優先で立ち上げたい。
まずは、dbtなどのモダンなツールを使ってDWH内でデータをきれいに保ちつつ(カタログ化)、それでも手に負えない「本当に複雑で汚いレガシー負債」に直面したときに、ACLという盾を構えるのが良いでしょう。



