Today I Learned

Recently I think about this phrase from Earl Nightingale a lot. "We become what we think about". This implies that our thoughts shape what we become.

If you think about failure every day, you're likely to fail. If you think about becoming a great engineer every day, you move in that direction. If you do NOT think about that every day, it won't gonna happen miraculously.

It makes sense to me. If you think about something everyday, you will have many opportunities to think about it, and that gives you many chances to take smaller steps directed towards it. In contrast when something is out of your mind, you'll most likely forget about it and when you remember it, months and years will have past. If just that thing was in your center of focus, you'd have lived such as different life.

It shows how important it is to control and direct your thoughts, especially the core parts. Any great goal, is not achieved in a day. It is the accumulation of what you do on a daily. So governing the daily you, is what enables you to steer yourself conciously.

One way you can do that is to do with journaling and reflection on the daily. More is not always better, if you have 10 things you want to be, that dillutes and often nothing remains. For me, pick only one thing and focus on that. And only once that is fully incoroporated into your focus, should you move on to incoroporate other things.

We become what we think about, so think about what you want to become.

DDD において腐敗防止層という大層な名前のものがある。 すごく重要であり、だからこそ大層な名前をつけているのだと思った。

実質変換行う "だけ" の外部と内部の間を取り持つ一種の「層」である。 内部とは DDD に基づいて実装している自分らのドメインモデルのことである。 外部とは連携しているレガシーシステムや他社の API などである。 これらの外部の都合につられて、ドメインモデルで同じような表現をしていたら、元も子もない。 外部の都合ではなく、ドメインモデルとしてどうあるべきに基づいてモデリングし、実装したい。 それを実現するには独立性が必要である。独立性を実現するには、内部と外部の間をよしなにしてくれるものが必要で、それが「腐敗防止層」に相当する。

腐敗防止層の話をすると Adapter, Facade, Translator が出てくる。これらはなんぞや？

これらが解決する問題を見よう。外部の都合に引きづられると困る問題として以下がある。

この問題を解消するのが以下

また、外部では REST API であったり SOAP API であったり XML を返したり JSON を返したりで、それらの都合もどこかで吸収したい。

でその問題を解消するのが Adapter。

これらを組み合わせて以下のような「腐敗防止層」が構成できる。（文字がちょい小さいが、、）

ドメインの表現と外部の表現の間に「腐敗防止層」があり、それが更に３つのサブ層からなっている。 Adapter でファイル形式やプロトコルの違いを吸収し、Facade でインターフェース・APIの粒度の違いを吸収し、Translator でフィールドの型・値・命名・構造などを変換して、ついに我々がドメイン表現に至る。

個人的には Facade のところが一番面白く学びが多いところであった。 Adapter と Translator の方が行っている処理については、まあ必要だろうなと思っていたが、Facade であー自分らの都合に合わせてインターフェースの粒度を調整するのか！という点は面白かった。 あとは純粋に Facade というワードチョイスがイケている。

これで ACL の初歩は掴めたのではないだろうか。

大きめの機能を開発するとき、もしくは CLEAN アーキテクチャを採用していて１つの機能開発が複数のレイヤーのサブチケットに分割されているときに、複数の Claude Code セッションで実装することになる。 このとき、そのセッション達が重要な情報を共有するための有効な手段がデフォルトではない。 Claude には Auto-memory という機能があり、プロジェクトレベルで重要なことを自動で記憶してくれる機能もあるが、機能レベルだと基本的にはない。 そこでその機能にまつわる重要な決まりごとを毎回説明するのも億劫であったり、他の方と分担して実装する場合もその決まりごとが正しく共有されていなかったりの問題が発生する。

このような問題の対処法として Feature Document という選択肢を知った。 Feature Document は機能の実装期間だけ生存するドキュメントである。 機能の重要な決まりごとを記載し、各セッションで読み込めんで共有し、実装中の追加決定事項があれば、その場で更新もできる。

具体的には、レポジトリのどこかに配置して git にチェックインしてもいいが、自分はまずは試験的に使うために以下の設定を使った。

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 においてこのロケーションの読み書き権限を追記し、権限許可を聞かれないようにもした。

これで、わりとうまい具合に、同一の機能開発に属するセッション間で情報・コンテキストを共有できるようになった。 使用していって、また知見があれば記載する。

ソース）martinFowler.com - Context Anchoring