Today I Learned

Bite-sized things I pick up day to day — tools, tricks, and tidbits worth remembering.

Anti Corruption Layer (ACL) / 腐敗防止層

Mar 19, 2026

DDD
DDD において腐敗防止層という大層な名前のものがある。 すごく重要であり、だからこそ大層な名前をつけているのだと思った。
実質変換行う "だけ" の外部と内部の間を取り持つ一種の「層」である。 内部とは DDD に基づいて実装している自分らのドメインモデルのことである。 外部とは連携しているレガシーシステムや他社の API などである。 これらの外部の都合につられて、ドメインモデルで同じような表現をしていたら、元も子もない。 外部の都合ではなく、ドメインモデルとしてどうあるべきに基づいてモデリングし、実装したい。 それを実現するには独立性が必要である。独立性を実現するには、内部と外部の間をよしなにしてくれるものが必要で、それが「腐敗防止層」に相当する。
腐敗防止層の話をすると Adapter, Facade, Translator が出てくる。これらはなんぞや?
これらが解決する問題を見よう。外部の都合に引きづられると困る問題として以下がある。
  • 型、表現形式、制約、命名など(一番分かりづらい部分)
  • 提供されているインターフェース(API)の粒度(連携先はの3つの取得 API でやっと我々がほしい1つのデータが得られるなど)
この問題を解消するのが以下
  • Translator -> 翻訳を担うパーツ。変換と聞いたら一番に思い浮かぶところ。
  • Facade -> これは「見せかけ」「仮面」などを意味する単語である。インターフェースおの粒度を自分らの都合のようように見せ方を替えるパーツ。
また、外部では REST API であったり SOAP API であったり XML を返したり JSON を返したりで、それらの都合もどこかで吸収したい。
でその問題を解消するのが Adapter。
これらを組み合わせて以下のような「腐敗防止層」が構成できる。(文字がちょい小さいが、、)
Anti Corruption Layer
ドメインの表現と外部の表現の間に「腐敗防止層」があり、それが更に3つのサブ層からなっている。 Adapter でファイル形式やプロトコルの違いを吸収し、Facade でインターフェース・APIの粒度の違いを吸収し、Translator でフィールドの型・値・命名・構造などを変換して、ついに我々がドメイン表現に至る。
個人的には Facade のところが一番面白く学びが多いところであった。 Adapter と Translator の方が行っている処理については、まあ必要だろうなと思っていたが、Facade であー自分らの都合に合わせてインターフェースの粒度を調整するのか!という点は面白かった。 あとは純粋に Facade というワードチョイスがイケている。
これで ACL の初歩は掴めたのではないだろうか。

Feature Document を使ってセッション間でコンテキストを共有する

Mar 18, 2026

AI 駆動開発
Claude Code
大きめの機能を開発するとき、もしくは CLEAN アーキテクチャを採用していて1つの機能開発が複数のレイヤーのサブチケットに分割されているときに、複数の Claude Code セッションで実装することになる。 このとき、そのセッション達が重要な情報を共有するための有効な手段がデフォルトではない。 Claude には Auto-memory という機能があり、プロジェクトレベルで重要なことを自動で記憶してくれる機能もあるが、機能レベルだと基本的にはない。 そこでその機能にまつわる重要な決まりごとを毎回説明するのも億劫であったり、他の方と分担して実装する場合もその決まりごとが正しく共有されていなかったりの問題が発生する。
このような問題の対処法として Feature Document という選択肢を知った。 Feature Document は機能の実装期間だけ生存するドキュメントである。 機能の重要な決まりごとを記載し、各セッションで読み込めんで共有し、実装中の追加決定事項があれば、その場で更新もできる。
具体的には、レポジトリのどこかに配置して git にチェックインしてもいいが、自分はまずは試験的に使うために以下の設定を使った。
  • ~/feature_documents/ ディレクトリを作る
  • プロジェクトの CLAUDE.local.md に以下のような指示を追記し、機能開発時に自動参照するように
When doing any kind of feature implementation, look at `~/feature_documents/` to see if there are any relevant feature documents.
If available, read that document and follow its instructions.
Also, if new decisions have been made about the feature or how to implement it that are specific to that feature, then update the document.
 
File format is `<date>-<content>` e.g. `2026-03-18-add-fuzzy-search`
本来はプロジェクト特化の情報のため、プロジェクト付近におくのが好ましいが、まずは試験的に導入ということでこのようにした。 個人の Claude 権限 ~/.claude/settings.json においてこのロケーションの読み書き権限を追記し、権限許可を聞かれないようにもした。
これで、わりとうまい具合に、同一の機能開発に属するセッション間で情報・コンテキストを共有できるようになった。 使用していって、また知見があれば記載する。