「データ」と「ロジック」の幸福な関係

「フレームワークのレールから外れる時、私たちは何を基準に設計すればいいのか？」

初期開発の生産性を支えてくれたフレームワークも、複雑なドメインロジックを抱えるようになると、Fatな実装や予期せぬ副作用（バグ）の温床となることがあります。 コードを上から下へ読む「手続き」のスタイルが、人間の記憶力の限界を超える瞬間です。

この課題に対し、自身の体験と歴史的背景（アラン・ケイの思想）を交えて、「データとロジックを近づける」ことの意味を再定義しました。 「完全性」と「不変性」を用いて、システムを信頼できる「聖域」にするためのアプローチについてまとめています。

Transcript

1. 「データ」と「ロジック」の幸福な関係 無秩序なメモリ操作を防ぐカプセル化 北尾 英之 @kitaohx 2026.01 「データ」と「ロジック」の幸福な関係 無秩序なメモリ操作を防ぐカプセル化 1
2. 本日の前提：私が向き合う領域 最初に、私がどのような開発をしているかお話しします。 領域: 基幹システム・バックエンド 特徴: 複雑な計算ルール、大量データの一括処理（バッチ） 本日お話しするのは、Web のCRUD 操作だけでなく、 こうした複雑なビジネスロジックと戦う中で見出した 「設計の指針」についてです。 「データ」と「ロジック」の幸福な関係 無秩序なメモリ操作を防ぐカプセル化 2
3. 認知負荷の限界 手続き型のコードを「上から下へ読む」 。 初期段階のプログラム開発では最適なのですが 業務システムなど、規模が大きくなると、 すぐに人間の「認知負荷」の限界を超えてしまいます。 課題 個人の記憶力に頼らず、未来の読み手にやさしい構成を目指す。 「データ」と「ロジック」の幸福な関係 無秩序なメモリ操作を防ぐカプセル化 3
4. フレームワークの功罪 Ruby on Rails などのフルスタックフレームワークは、 開発において高い生産性を発揮します。 この「レール」に乗る体験は素晴らしく、機能開発は加速します。 しかし、私の扱う「複雑な業務ロジック」を そのままレールに乗せようとした時、問題が起きました。 「データ」と「ロジック」の幸福な関係 無秩序なメモリ操作を防ぐカプセル化 4
5. 「Fat な実装」の発生 標準レイヤーに複雑さを収めようとすると… Fat な実装: 本来の役割以外の処理が入り、可読性が下がる。 見えない副作用: 変数や機能が意図せず共有される。 結果「ここを直すと、あっちが壊れるかも」という恐怖に 「データ」と「ロジック」の幸福な関係 無秩序なメモリ操作を防ぐカプセル化 5
6. レールを外れる覚悟と、新たな問い こうなった時、フレームワークという「レール」が ない状態で設計する必要があります。 「データ」と「ロジック」の幸福な関係 問い 「レール（標準的な置き場所） 」がないなら、 私たちは一体何を基準にコードを配置し、設計すればいいのか？ “ “ 無秩序なメモリ操作を防ぐカプセル化 6
7. アラン・ケイの「細胞」 計算機科学の先駆者アラン・ケイは、 システムを「生物学的な細胞」の集まりとして構想しました。 1. 細胞は「細胞膜」で守られている。 2. 外部から内部（核）を直接いじれない。 3. できるのは「メッセージ」を送ることだけ。 「データ」と「ロジック」の幸福な関係 無秩序なメモリ操作を防ぐカプセル化 7
8. メモリ管理としての「細胞膜」 これを私なりに「メモリ管理」の観点で読み解きます。 つまり 「細胞膜で守る」とは あるオブジェクトが管理するメモリ領域（変数）を、 外部から直接書き換えさせない（直接操作を遮断する） ということです。 「データ」と「ロジック」の幸福な関係 無秩序なメモリ操作を防ぐカプセル化 8
9. 構造のイメージ（カプセル化の恩恵） 「誰かが、中身を勝手に書き換えるかも」という不安が消えれば、 読み手は内部事情（詳細）が壊れないかを 心配する必要がなくなります。 詳細（中身の管理） オブジェクトに任せる。 ロジック（どう使うか） 人間はこちらに集中する。 「データ」と「ロジック」の幸福な関係 信頼できる「部品」として扱えるようになります。 “ “ 無秩序なメモリ操作を防ぐカプセル化 9
10. 読み手にやさしい書き方とは 次に２つの原則を紹介します。 読み手にやさしく（＝認知負荷を低減）するための手法です。 完全性 不変性 （注意） これらは教義ではなく、常に適用する必要はありません。 「レール」から外れる際に、考慮すべき設計手法です。 「データ」と「ロジック」の幸福な関係 無秩序なメモリ操作を防ぐカプセル化 10
11. 原則①： 「完全性」 「オブジェクトは生まれた瞬間から完全である」 「とりあえず空で作って、後でSetter で値を入れる」をやめます。 コンストラクタで必須データを強制します。 すると、クラスを利用する側が、 if (value != null) などの防御的な記述から解放されます。 「データ」と「ロジック」の幸福な関係 無秩序なメモリ操作を防ぐカプセル化 11
12. データの流れ（複雑な業務ロジックを扱う聖域） クリーンアーキテクチャの同心円をイメージしてください。 1. 円の外側の世界 値があるかどうかすら疑うべき生データ 円の境界で厳密に検査（バリデーション） 2. 円の内側の世界 完全・不変なオブジェクト 純粋な業務ロジック 「データ」と「ロジック」の幸福な関係 無秩序なメモリ操作を防ぐカプセル化 12
13. 原則②： 「不変性」 「一度作ったオブジェクトは変更しない」 変数が書き換わるコードは、 「今の値」だけでなく 「いつ、どの順序で変わったか？」 という時間軸も追う必要があります。 これは脳のワークスペースを圧迫します。 「データ」と「ロジック」の幸福な関係 無秩序なメモリ操作を防ぐカプセル化 13
14. 「システム1 （速い思考） 」 不変（Immutable ）なら、 「いつ読んでも値は同じ」 。 つまり、時間軸を無視できます。 システム2 （遅い思考） 注意深く分析する。可変状態を追うのに必要。 システム1 （速い思考） 直感的。不変ならこちらでスラスラ読める。 「データ」と「ロジック」の幸福な関係 無秩序なメモリ操作を防ぐカプセル化 14
15. 実践： 「値オブジェクト」 原則をどう適用するのか その具体例の１つが「値オブジェクト」です。 例：メールアドレス String 型 どんな文字列も入る。チェック処理が散らばる。 Email クラス @ などがないと生成不可（完全性） 。一度作れば不変（不変性） 。 「データ」と「ロジック」の幸福な関係 無秩序なメモリ操作を防ぐカプセル化 15
16. ロジックの凝集 独自の型を作れば、 バリデーション等のロジックは Email クラスに集まります。 この現象が「関心の分離」です。 ロジックが、本来あるべき場所 （データ自身のそば）に吸い寄せられていくのです。 「データ」と「ロジック」の幸福な関係 無秩序なメモリ操作を防ぐカプセル化 16
17. 副産物：テストの圧倒的な速さ 複雑な業務ロジックを「円の内側」に集約することで ロジックをフレームワークやDB から切り離した 「純粋なクラス」となりました。 そのため、テストが速いという特徴がありました。 「純粋なクラス」はメモリ上で動作が完結したのです。 従来: DB 接続などで重い・遅い。 本手法: メモリ上で完結。0.01 秒で終了。 「データ」と「ロジック」の幸福な関係 無秩序なメモリ操作を防ぐカプセル化 17
18. 変更への恐怖を消す 「データの準備（I/O ） 」と「計算（ロジック） 」を分けます。 最も複雑なロジック部分は、DB もネットワークも使いません。 結果、テスト実行するとすぐに「ロジックは壊れていない」と 判断でき、安心感が得られ、品質を支えます。 「データ」と「ロジック」の幸福な関係 無秩序なメモリ操作を防ぐカプセル化 18
19. 結論 「データとロジックを近くに置く」 これは整理整頓ではなく、 無秩序なメモリ操作の物理的な防止（隠蔽）です。 完全性: 「正しく動く」信頼。 不変性: 「値は同じ」という安心。 これらの手法により、複雑な業務ロジックを読み解く際に 認知負荷を下げ、結果的に、変更に強い構造となります。 「データ」と「ロジック」の幸福な関係 無秩序なメモリ操作を防ぐカプセル化 19
20. Appendix. 何を書くべきか？ オブジェクト（細胞）の中に書くのは、 DB 操作や通信などの「技術的な話」ではありません。 書くべきは内部の状態に対する「計算」と「ルール」です。 例： バリデーション: 正しい形式か？ 計算: 単価× 個数＝合計。 比較判定: 日付の矛盾はないか？ 状態遷移: 次へ進んでよいか？ 「データ」と「ロジック」の幸福な関係 無秩序なメモリ操作を防ぐカプセル化 20