ここでは、「何を中心概念としてシステムを開発するか」という観点から、これまでの開発手法がどのように移り変わってきたのかを順に説明します。
プロセス中心アプローチ（POA）
最初は、業務処理の流れ（プロセス）に沿ってシステムを開発する方法が一般的でした。
これをプロセス中心アプローチ（POA：Process Oriented Approach）と呼びます。
下図は、プロセス中心アプローチ（POA）のイメージ図です。
処理間の矢印は処理の流れ（処理フロー）を表し、データは各処理の入出力として扱われます。
しかし、このプロセス中心アプローチ（POA）には次のような問題がありました。
- 処理の複雑化
「注文」が「請求」に、「請求」が「入金」に依存しているため、一つの処理を変更すると他の処理にも影響が波及しやすく、いわゆるスパゲッティ構造になりがちでした。
その結果、テストや保守が非常に複雑になります。 - データの不整合
各プロセスがそれぞれ独自に「顧客データ」や「注文データ」を保持していたため、たとえば請求処理で顧客住所を修正しても、注文処理側の顧客住所は古いまま残るなど、データの整合性が保てないという問題が発生しました。
この2つの問題（処理の複雑化とデータの不整合）を解決するために考えられた手法が、トム・デマルコ（Tom DeMarco）による「構造化分析（Structured Analysis）」です。
構造化分析は、これらの問題を解消するために、大きく次の2つの考え方を示しました。
- 処理のモジュール化
各プロセスを独立した「箱」として整理し、モジュール化します。
さらに、モジュールを階層的に分解することで、スパゲッティ構造だった処理を木構造として再構成し、全体の見通しを改善します。 - データストアとデータフローの明確化
顧客や商品などの永続的なデータを「データストア」として独立させ、これまでの処理の流れ（処理フロー）ではなく、処理とデータストア間のデータの流れ（データフロー）を明確にします。
これにより、「どのデータをどこで使うか」が可視化され、データが局所化されて不整合が減少します。
この考え方を具体的に表現する図法が、データフロー図（DFD：Data Flow Diagram）です。
構造化分析は、処理を構造化するとともに、データの流れを明確化する手法といえます。
ただし、構造化分析はデータを構造化して一元管理するという考え方までは明確に提示していません。
そのため、処理に依存したデータが散在する問題は依然として残りました。
たとえば、以下のような状況が起こり得ます。
- 注文処理で使う顧客データ → {顧客ID, 顧客名, 住所}
- 請求処理で使う顧客データ → {顧客ID, 顧客名, 住所, 支払条件}
- 入金処理で使う顧客データ → {顧客ID, 顧客名, 銀行口座}
結果として、処理の複雑化はモジュール化によって大きく改善された一方で、データの不整合を完全に解決することはできませんでした。
データ中心アプローチ（DOA）
そこで、処理からデータを完全に分離し、データを構造化して全体で一元管理することによって、データの不整合を解消しようとするデータ中心アプローチ（DOA：Data Oriented Approach）が登場しました。
下図は、データ中心アプローチ（DOA）のイメージを表したものです。
これを見ると、処理からデータが明確に分離され、全体で一元管理されていることがわかります。
データは「データベース」という管理機構によって統合的に管理され、個々のデータの属性やデータ間の関係が明確に定義され、構造化されています。
このデータの属性や関係を定義する手法が ERモデル（Entity Relationship Model）、そしてその構造を可視化する図法がER図（Entity Relationship Diagram）です。
データ中心アプローチ（DOA）によって、データの不整合は大きく解消されました。
しかし、一元化されたデータ構造に多くの処理が依存するため、データ構造が変更されると多くの処理に影響が及ぶという新たな問題が生じました。
DOAの思想の根底には、
「処理は業務改善などによって頻繁に変わるが、業務の本質を表すデータ構造は比較的安定している」
という考え方があります。
しかし実際には、データ構造も属性の追加や関係の拡張など、少しずつ変化していきます。
その結果、全体で一元化されたデータにアクセスする処理が増えるほど、データ構造変更の影響範囲が拡大し、処理の追加や変更の柔軟性が低下してしまいました。
この問題を回避するため、データにアクセスできる処理の範囲を限定し、業務単位でパッケージ化するようになりますが、業務パッケージの変更コストが高いため、似たようなパッケージが乱立し、結果としてシステムと業務のサイロ化が進むことになります。
オブジェクト指向アプローチ（OOA）
データ中心アプローチ（DOA）は、処理からデータを完全に分離し、データを構造化するとともに全体で一元管理する手法です。
その一方で、このDOAの思想に対するある種のアンチテーゼ（対抗思想）として登場したのが、オブジェクト指向アプローチ（OOA：Object Oriented Approach）です。
オブジェクト指向アプローチの根底には、次のような考え方があります。
「現実世界のモノ（Object）は、データ（状態）と振る舞い（操作）を一体として持つ。
これをソフトウェアの世界でも同じように表現しよう。」
OOAでは、データとそれに対する操作（処理）をオブジェクトの中にカプセル化し、外部からそれらを隠蔽することで、データや処理の変更による影響を局所化します。
さらに、オブジェクト同士がメッセージのやり取りにによって連携することで、システム全体を構成します。
この仕組みにより、オブジェクトの再利用性・保守性が向上し、結果としてシステム開発全体の生産性と柔軟性を高めることができます。
また、データと処理を一体化したオブジェクトを抽象化した型が「クラス」であり、その構造を表現する図法がUML（Unified Modeling Language）のクラス図です。
現在広く利用されている Java、JavaScript、Python などのプログラミング言語は、このオブジェクト指向アプローチ（OOA）の考え方を実現するために設計されたオブジェクト指向型プログラミング言語です。
ところで、オブジェクトが保持するデータを永続化（保存）するためには、データベースが必要になります。
そこで、データの永続化を担うオブジェクトとしてリポジトリ（Repository）やDAO（Data Access Object）が導入されました。
しかし、この永続化層とデータベースの間でも、データ構造が変更されると多くの処理に影響が及ぶという、DOAと同様の問題が発生します。
つまり、オブジェクトの数が増えれば増えるほど、データ構造の変更に伴うリスクが増大し、結果としてシステムの堅牢性（変化に対する強さ）が低下していくのです。
現在、多くのシステムは、まさにこのような構造を持っているのではないでしょうか。
ドメイン駆動設計×マイクロサービス
データ構造の変更によるリスクを抑えるための方法の一つに、データにアクセスできるオブジェクトの範囲を限定するという考え方があります。
このオブジェクトの範囲、すなわちドメインを中心にシステムを設計する手法が、ドメイン駆動設計です。
ドメイン駆動設計（DDD）とは、ドメイン（開発対象となる業務領域）を中心に据えて、システムを設計・開発する手法です。
この手法により、業務の本質を表すドメインの構造や振る舞い（業務ルールや機能）を正確にモデル化でき、再利用性や拡張性が高く、変化に強い堅牢なシステムを構築することが可能になります。
DDDの重要なポイントは、技術的な設計よりも、まず組織全体で適切な業務領域（ドメイン）をどのように定義し設計するかにあります。
すなわち、ドメイン駆動設計の本質は、究極的には業務の仕組みそのもの、すなわちビジネスアーキテクチャの設計にあるといえます。
一方で、システムを構成する要素を、独立してデプロイ可能な小さなソフトウェア部品に分割し、それぞれが実現するサービスを他の部品に提供し合うことで全体のシステムを構成するという考え方が、マイクロサービスです。
一つのマイクロサービスは、そのサービスを実現するために必要なデータベースも内包します。
したがって、マイクロサービスはデータベースを含めて処理とデータをカプセル化した自律したソフトウェア部品となります。
このように、ドメイン駆動設計によって設計されたドメインごとにマイクロサービスを構築し、それらを疎結合で連携させることで、ビジネスとITが一体となり、環境の変化に柔軟に適応できる「変化に強いシステム」を実現することができます。
