ソフトウェア、外から作るか?内から作るか?
アプリケーションの構造をクリーンアーキテクチャのように考えた時、実際の設計をどの順にやるかという問いがある。
https://gyazo.com/1c992b80ba564480d87ff9d685a8a153
外側のインターフェース層から設計を始めて内側のドメイン層に向かう「アウトサイドイン」と、逆に内側のドメイン層から設計を始めて外側に向かう「インサイドアウト」という2つのアプローチが考えられる。どちらのアプローチを取るかについては議論が分かれている。
アウトサイドイン派
ソフトウェアを設計する際、本当に必要なものは何か? 第一には何を作っているかを理解することである。そのためには目に見えるUIが先になくてはならない。概念だけではダメで、小さな詳細を見落とすだけで後で痛い目に遭う可能性がある。
時には、不足しているデータがデータベースに存在しないこともあるし、リアルタイムで計算するにはコストがかかりすぎることもある。それがユーザーにとって重要で非常に便利なものであれば? それに対応するためにアーキテクチャを修正することになる。しかし、後で書き直す必要がないよう、事前にこの詳細を知っておく方が良い。
したがって、UI → DB → Backend (ドメインモデル)の順に設計すべきだ
コードを書きだす前に、UIがどのようになるかについて、かなり明確なイメージを持っておくべきだ。
UIはペーパープロトタイピングで構わない
インサイドアウト派
エンタープライズシステムでは必ずしもUIに現れない複雑なビジネスロジックが存在する。ドメインロジックの認識なしではアジャイルは失敗する。
機能重視のアジャイルプロセスから、ドメイン中心のモデリングに切り替えることで、別に作業は速くなったわけではないが、実績としてバックログが安定し、手戻りが減り、デリバリー速度が向上した。
典型的な DB-First の構造では、Presentation → Business → Data (永続化層)というレイヤー構造を取り、Business層からData層への明示的な依存が生まれる
実際には Data 層(または ORM を介した DB モデル)が Business 層や Presentation 層に漏れ出し、ビジネスロジックが DB や永続化の詳細と混ざり、「スパゲッティ化」や “Big Ball of Mud”(大きな泥団子)アンチパターンに陥りがちである。
Domain-First では、ドメイン層(エンティティ、ビジネスルール、ユースケースなど)がアプリケーションの中心にあり、外側（DB, UI, フレームワークなどの “詳細”） はアダプタやインタフェースを介して接続される設計となる。これにより、ドメイン層は永続化や UI の変化の影響を受けず、安定したビジネスロジックを保てる。
ただし、“純粋な形のドメイン中心アーキテクチャ” を盲目的に採用すべきではない。プロジェクトの規模、複雑性、要件によっては、DB-First のようなシンプルな設計で十分であり、過剰な抽象化はかえって負荷になる可能性がある。
SIでよく見かけるアウトサイドイン
ニューレガシーアンチパターンに示しているように、画面駆動設計およびテーブル駆動設計で外側から開発を進め、早い段階で画面を軸に担当者を割り当ててサイロ化するのが、典型的なエンタープライズシステム開発の進め方である。 早期サイロ化により、ドメインモデルが議論される余地がなくなる。
https://gyazo.com/e80d0efd014a89a55b2dd914bd653aa6
抽象概念を喪失したアウトサイドインが悪
アウトサイドイン派もインサイドアウト派も一理あって、どちらか一方に拘泥するのは良くないように見える。だが、SIでよく見かけるアウトサイドインは明らかに問題があるように見える。
アウトサイドイン派 vs インサイドアウト派の議論では、単にアプローチの違いであって最終的にドメインモデルは必要という前提の上に成り立っている。それに対し、SIでよく見かけるアウトサイドインは、早期サイロ化によってドメインモデルがそもそも作られない。
ここでのドメインモデルは実装ではなく、業務で扱うデータと振る舞いの抽象概念を指す。ある機能で扱う注文と、別の機能で扱う注文が同じものを指すのか? 違いがあるとすれば何か? 「注文を受け付けた」とするには、どういう状態でなくてはならないか? などが正しく設計・実装されていないと機能間での仕様差異を生んでしまう。