こまぶろ

技術のこととか仕事のこととか。

リレーショナルモデルと『Clean Architecture』のエンティティ

(エリック・エヴァンスの)ドメイン駆動設計を入り口にして、オブジェクトモデルとリレーショナルモデルについて考えているなかで、「ドメインモデルって必ずしもオブジェクトじゃなくていいんじゃないの」という思いを強めている。

ky-yk-d.hatenablog.com

そのような観点で、改めてアンクル・ボブの『Clean Architecture』を眺めていたら、一読したときは読み飛ばしていた記述に引っかかったので、覚書を残す。

Clean Architecture 達人に学ぶソフトウェアの構造と設計

Clean Architecture 達人に学ぶソフトウェアの構造と設計

『Clean Architecture』におけるエンティティ

アンクル・ボブの『Clean Architecture』において、エンティティ*1は以下のように説明されている。

エンティティは、企業全体の最重要ビジネスルールをカプセル化したものだ。エンティティは、メソッドを持ったオブジェクトでも、データ構造と関数でも構わない。企業にあるさまざまなアプリケーションから使用できるなら、エンティティは何であっても問題はない。*2

ビジネスルールをカプセル化したものがエンティティである。そして、それは必ずしもオブジェクト指向モデルによって表現されるものではない。ビジネスルールをカプセル化したものが、複数のアプリケーションから利用されるというのが、アンクル・ボブの描く絵だ。

リレーショナルデータベースはエンティティたり得ないのか

データ構造とその操作によってビジネスルールを表現するということであれば、【リレーショナルモデルにおけるデータ構造+SQLによる操作】を提供するリレーショナルデータベースもまた、エンティティたりうるのではないか、という疑問が生じる。

そもそも、データベースというものは、複数の箇所からアクセスされることを想定したものである点で、単なる永続化手段であるファイルとは異なる。

ファイルはプログラムに「隷属したデータ群」である。一方、データベースはデータをプログラム群から切り離し(=独立させ)、データベース管理システムにより統合して管理・運用しようとするもので、「多数のユーザから同時にアクセス可能な組織体の唯一無二の共有資源」となる。*3

このような見方をすると、データベースというものが「企業にあるさまざまなアプリケーションから使用できる」というエンティティの一つの特質を満たそうとするものであるということがわかる。

「リレーショナルデータベース」はエンティティではない

しかし、別の箇所で、アンクル・ボブはまず、データベースをエンティティと捉えることを明確に否定している。

 アーキテクチャの観点では、データベースはエンティティではない。データベースは詳細であり、アーキテクチャの構成要素として現れることはない。ソフトウェアシステムのアーキテクチャにおけるデータベースの立ち位置は、あなたが住む家におけるドアノブのようなものだ。
 ケンカを売っているように聞こえるかもしれない。実際、論争になったこともある。念のために言っておくが、今話題にしているのはデータモデルのことではない。アプリケーションのデータをどのような構造で扱うかは、システムのアーキテクチャにおいて重要な問題だ。*4

上の記述では、「データベース」を、したがって「リレーショナルデータベース」をエンティティとは認めないという明確な姿勢が示されている。しかし一方で、「データモデル」については別の問題だとし、判断を留保しているように見える。

「リレーショナルモデル」はエンティティのためのデータ構造ではない

しかし、さらに読み進めていくと、アンクル・ボブは、ビジネスルールを取り扱うためのデータ構造として、リレーショナルモデルを認めていないように読める記述がある。

さて、ここで考えてみよう。ディスクが絶滅し、すべてのデータがRAMに格納されるようになったとき、どのようにデータを扱うだろうか?表形式にしてSQLでアクセスする?それともファイルとして保存してディレクトリで管理する?もちろんそんなことはしないだろう。リンクリスト、ツリー、ハッシュテーブル、スタック、キューなどでデータ構造を表現し、ポインタや参照でデータにアクセスするだろう。だって、それがプログラマのやり方なのだから*5

「表形式にしてSQLでアクセスする」のは、リレーショナルモデルのことだろう。上の記述においては、ディスクが絶滅した世界を前提にしているから、インメモリのリレーショナルデータベースをイメージすればよい。SQLビジネスロジックを実装することもできるから、インメモリのリレーショナルデータベースをエンティティとしてビジネスロジックの担い手とすることもできるはずだ。しかし、アンクル・ボブはこれを否定するのである。

むすび:データ構造とデータモデル?

アンクル・ボブは、全てがメモリ上で行われる世界においては、「プログラマのやり方」が用いられるだろうと主張する。それは、「リンクリスト、ツリー、ハッシュテーブル、スタック、キューなど」のことである。これらのデータ構造は、オブジェクトモデルとの必然的結びつきを持たないと思う。

一方で、「リレーショナルモデル」は、上記のデータ構造とは異質なものとしてアンクル・ボブによって扱われている。上記で言われているようなデータ構造よりも、(リレーショナルあるいはオブジェクトといった)データモデルの方がより抽象的だと思うが、いまいち整理ができていない。Wikipediaの「データモデル」の項目には、「データ構造」という節があるが、関係性は明確ではない(単独の「データ構造」という項目も存在する。)。

データ構造とデータモデルについての明晰な整理を自分が欠いているということもあるだろうが、エンティティとしての資格をデータベース更にはリレーショナルモデルに認めないという論述に関しては、「プログラマのやり方」という語彙を含め、アンクル・ボブには誤魔化されているような感覚を覚えるというのが今のところの正直な感想である。

参考

a-suenami.hatenablog.com

*1:『エリック・エヴァンスのドメイン駆動設計』におけるエンティティとは区別されなければならない。

*2:『Clean Architecture』201ページ。

*3:増永良文『リレーショナルデータベース入門 第3版』4-5ページ。

*4:『Clean Architecture』259ページ。

*5:『Clean Architecture』262ページ。強調は原文。