最近、「WEB+DB PRESSの"DDD"の記事が良かったよー。」みたいな話を小耳に挟んだので、一体、どんなモノなのか？を調べてみました。多分、この辺を見ればイイんンじゃないか？と。


　ちなみに、「DDD」とは、ドメイン駆動設計（Domain-driven design）の事で、クリーン・アーキテクチャとは「DDD」で推奨されているアーキテクチャとの事でした。また、タイトル中の「OOAD」とは、オブジェクト指向分析設計（object-oriented analysis and design）の事です。

　クリーン・アーキテクチャについて、ざっくり説明すると、


　的なノリのモノですね（技術的に説明すると、依存関係を、UIサブシステム や データ・プロバイダ等の外からビジネス・オブジェクト等の中だけに向けることで実現する）。

　...で、コレ等を見てみると、「なんか、コレ、ASP.NET Core Identity で 1 / 3 位はヤってるな。」と言う感じがしました。具体的には、


　みたいな感じでしょうか？

＜参考＞

• マイクロソフト系技術情報 Wiki
• DI
• 依存性反転原則

　実際、ASP.NET Core Identity辺りと、クリーン・アーキテクチャの関係を調べると、MicrosoftもMicrosoft Docs中で「クリーン・アーキテクチャがー。」言うてるので、ある程度の部分は、実践投入されているように思います。


　更に（、前述の）、「ASP.NET Core Identity のテンプレートで出来ていない部分の対応を行う。」的なサイト（当然海外）も発見したりしました。


　（...この例だと、別途、Interactorを作成して、Repositoryの中でManagerを使ってますね。）...また、たまたまTwitterのタイムライン中で発見したんですが、Rubyには、Hanamiというクリーン・アーキテクチャを志向したフレームワークがあるようです。


　...と言う事で、クリーン・アーキテクチャ（に近いモノ）に関しては、小規模アプリケーションでは試験的に実践投入されているように思います。

　クリーン・アーキテクチャの「試験的に。」を取り払うには、そう言うプロダクト や テンプレートが、GitHub上に上がり始め、最終的に、IDE上のRAD機構等で採用されたりすればイイと思います。良く出来てたら、みんな真似したり、使ったりします。

　ただ、実際は、コンパチのシナリオが運用上、発生しないというオチが案外多い気がしています（他にも、位置透過性 / 異種透過性と、性能問題とか、分散オブジェクト云々言っていた頃から色々あるので...）。

　また、DDDは、より大規模なアプリケーション開発で導入されるべき設計で、


　といった高位の概念と実践について多数述べられているらしく、なんか、OOADを思い出してしまう訳です。

　コレ（OOAD）については、過去に、「カタストロフィ的芸風について考える。」に書きましたので、まぁ、これを実践投入する場合は、先ずは、「新技術導入とか言うアレに対してチョット思った事を書いた。」に書いた点に留意し、節度を守って絡むのがイイんじゃないか？と思ったりはします。

＜参考＞

---

　余談：

　ちなみに、Open棟梁では、通信制御機能により、P層、B層の差し替え、また、トランザクション制御機能により、データ・プロバイダの差し替えが可能になっています（ADO.NET規格の範囲内ならコンパチ可能）。

　しかし、データ・アクセスのフレームワークを変更するようなケース（ADO.NET → Dapper）では、D層自体を差し替えるか、フレームワーク自体をデータ・アクセス制御クラス中に押し込む必要があり、これについては、既定ではサポートしていません（サポートを追加することはできると思いますが）。

　ただ、問題の本質は、「実は、D層周りの差し替えが必要性になるケースがあまり無い。」と言う事じゃないか？と思います。


　従って、実際やろうとすると、レアケースにどれだけ投資するのか？みたいな問題が、必ず浮上してくると思います。そこで決定打が無いと、基本的には優先度が下がって、採用されないプロジェクト、若しくは、優先度の低いバックログ・アイテムにしかならないと思います。

＜参考＞