【Clean Architecture座談会】第3回

mohikanzというエンジニアコミュニティで、Clean Architectureを読んだ人で集まってオンライン座談会を始めました。

Clean Architecture　達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ)

第1回と第2回のレポートはこちらです。

今回は第3回として、16章「独立性」から20章「ビジネスルール」までのグラレコとなります。

16章　独立性

この章はデプロイの話に花が咲きましたが、Clean Architecture関係無かったような気もします。

ユースケースの切り離しという内容があったので、参加者の方からのFBを元にClean Architectureの同心円をケーキのように切る絵を描いてみました。ここで使われる「ユースケース」と同心円の図に書かれているユースケースは別物そうだ、ということで意見が一致しました。

17章　境界線を引く

丁度昨日「エリック・エヴァンズのドメイン駆動設計」を読み始めた所だったのですが、これはモデリングの話にも通じると感じました。

個人的には、Database Interfaceを切る意味を自分が理解していなかった事に衝撃を受けました。「DBに依存したくないんでInterface切ります（キリッ）」と言い続けて来たのですが、Database Interface自体はビジネスルールに属するという事をもっと自覚的になるべきでした。どのような形・単位でデータ永続層とやり取りするのかそれ自体はビジネスルールなのです。Database Interfaceに脳死でCRUDのインターフェースを用意するのは、DBに依存しているのと同じです。結果的にCRUDのインターフェースを用意したとしても、この事には自覚的でありたいな。

18章　境界の解剖学

この章では巨大なモノリシックなシステムを分割するとしたらどのような単位が考えられるのかという内容で、そこまで話した事も無かったです。

19章　方針とレベル

この章もあまり話は弾まず。レベルの定義の話でした。

20章　ビジネスルール

この章ではエンティティがユースケースより上位に当たる、ということが言われています。実際に同心円の図ではエンティティが中心、ユースケースが外側（入出力側に近い）に配置されています。

自分がここで疑問に思ったのは「同心円の図ではDBは最も外側に書かれているが、DBは上位レベルなのでは？　同心円の図はレベルを表すものではない？」ということでした。クライアントが入力した情報を元に何らかの情報を返却（出力）するとして、クライアントからは遠いと考えたためです。

ただ、DBは出力先のひとつであるという理解で見直すと、同心円の図は外側ほど低レベルという理解で問題無さそうです。

余談　DDDとClean Architecture

今回よくDDDの話が出たので、軽くその話にもなりました。メモ書き程度ですが残しておきます。

全体通して

Database Interfaceの意義を理解できていない事に気付いたのはショックではありますが大変有益でした。今後もこういう根本的な部分での認識漏れを埋めていくため、徹底的に対話をしていきたいと思います。