はじめに:きれいなコードを書きたいのに…

エンジニアなら誰しも、「きれいで、読みやすくて、変更しやすいコード」を書きたいと思いますよね。 でも、現実のプロジェクト、特に歴史のある「レガシーシステム」と連携するとなると、話は一気に難しくなります。

  • 「なんでこのカラム名、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)の中の人】がやってくれること

  1. ゴミを捨てる(フィルタリング)
    • 通訳さん:「おっと、del_flg = '1'(削除済み)のデータは、新しいシステム(Redshift)には必要ないね。ここで捨てておこう」
  2. 意味を翻訳する(セマンティック変換)
    • 通訳さん:「この type = '2' っていうのは、ソースコードを読むと『法人定期』という意味か。よし、新しいシステムには 'CORPORATE_SUBSCRIPTION' という分かりやすい名前に翻訳して伝えよう」
  3. 型を整える(構造変換)
    • 通訳さん:「JSON文字列のままだとRedshiftで計算しにくいな。パース(解析)して、total_amountdiscount_amount という数字のカラムに展開しておこう」
  4. 計算しておく(事前計算)
    • 通訳さん:「正味の売上金額(Net Sales)は、分析でよく使うはずだ。ここで 5000 - 200 = 4800 と計算して、net_sales_amount というカラムを作っておこう」

【出力】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という盾を構えるのが良いでしょう。


この記事が気に入ったら『目黒で働く分析担当の作業メモ』ご支援をお願いします!

※OFUSEに飛びます


おすすめの記事