最近、「WEB+DB PRESSの"DDD"の記事が良かったよー。」みたいな話を小耳に挟んだので、一体、どんなモノなのか？を調べてみました。多分、この辺を見ればイイんンじゃないか？と。
ちなみに、「DDD」とは、ドメイン駆動設計（Domain-driven design）の事で、クリーン・アーキテクチャとは「DDD」で推奨されているアーキテクチャとの事でした。また、タイトル中の「OOAD」とは、オブジェクト指向分析設計（object-oriented analysis and design）の事です。
クリーン・アーキテクチャについて、ざっくり説明すると、
「クリーン・アーキテクチャのビジネス・オブジェクト的なものは、アーキテクチャ（例えば、UIサブシステム や データ・プロバイダ）が、変更されても、変更されない（プログラム修正は不要）。」
的なノリのモノですね（技術的に説明すると、依存関係を、UIサブシステム や データ・プロバイダ等の外からビジネス・オブジェクト等の中だけに向けることで実現する）。
...で、コレ等を見てみると、「なんか、コレ、ASP.NET Core Identity で 1 / 3 位はヤってるな。」と言う感じがしました。具体的には、
「ASP.NET Core Identity の Controller より中の Interactor は ManagerとしてDIされている。
Repositoryは、下記の"依存性反転原則"で説明されているもので、実装としては、IUserStoreインターフェイスを継承するUserStoreクラスとなっており、Entity Frameworkとその他のデータ・アクセスのフレームワークを差し替えが可能になっている。
また、ASP.NET Coreからは、データ・アクセス（Entity Framework）のDIも用意はされているが、インターフェイスが異なるので、これに意味があるかどうか不明。」
みたいな感じでしょうか？
＜参考＞
実際、ASP.NET Core Identity辺りと、クリーン・アーキテクチャの関係を調べると、MicrosoftもMicrosoft Docs中で「クリーン・アーキテクチャがー。」言うてるので、ある程度の部分は、実践投入されているように思います。
更に（、前述の）、「ASP.NET Core Identity のテンプレートで出来ていない部分の対応を行う。」的なサイト（当然海外）も発見したりしました。
（...この例だと、別途、Interactorを作成して、Repositoryの中でManagerを使ってますね。）...また、たまたまTwitterのタイムライン中で発見したんですが、Rubyには、Hanamiというクリーン・アーキテクチャを志向したフレームワークがあるようです。
...と言う事で、クリーン・アーキテクチャ（に近いモノ）に関しては、小規模アプリケーションでは試験的に実践投入されているように思います。
クリーン・アーキテクチャの「試験的に。」を取り払うには、そう言うプロダクト や テンプレートが、GitHub上に上がり始め、最終的に、IDE上のRAD機構等で採用されたりすればイイと思います。良く出来てたら、みんな真似したり、使ったりします。
ただ、実際は、コンパチのシナリオが運用上、発生しないというオチが案外多い気がしています（他にも、位置透過性 / 異種透過性と、性能問題とか、分散オブジェクト云々言っていた頃から色々あるので...）。
また、DDDは、より大規模なアプリケーション開発で導入されるべき設計で、
「システムを実装するための特定の技術ではなく、ドメインそのものとドメインのロジックに焦点を置くべき」（Wikipediaより引用）
といった高位の概念と実践について多数述べられているらしく、なんか、OOADを思い出してしまう訳です。
コレ（OOAD）については、過去に、「
カタストロフィ的芸風について考える。」に書きましたので、まぁ、これを実践投入する場合は、先ずは、「
新技術導入とか言うアレに対してチョット思った事を書いた。」に書いた点に留意し、節度を守って絡むのがイイんじゃないか？と思ったりはします。
＜参考＞
余談：
ちなみに、Open棟梁では、通信制御機能により、P層、B層の差し替え、また、トランザクション制御機能により、データ・プロバイダの差し替えが可能になっています（ADO.NET規格の範囲内ならコンパチ可能）。
しかし、データ・アクセスのフレームワークを変更するようなケース（ADO.NET → Dapper）では、D層自体を差し替えるか、フレームワーク自体をデータ・アクセス制御クラス中に押し込む必要があり、これについては、既定ではサポートしていません（サポートを追加することはできると思いますが）。
ただ、問題の本質は、「実は、D層周りの差し替えが必要性になるケースがあまり無い。」と言う事じゃないか？と思います。
「ASP.NET Identityなどのフレームワークの場合、ユーザストアがRDBMS、LDAP、NoSQLなどのケースを考えることは可能なので、DDDと言うか、クリーン・アーキテクチャが有意義になる可能性はあるかと思います。
...が、業務系だとストアが、ほぼRDBMSになるので、過去にUIサブシステム や データ・プロバイダを差し替えることは何回かありましたが、P層から見て、B層を差し替えたり、B層から見てD層を差し替えることは、ホボ、無かったですね。」
従って、実際やろうとすると、レアケースにどれだけ投資するのか？みたいな問題が、必ず浮上してくると思います。そこで決定打が無いと、基本的には優先度が下がって、採用されないプロジェクト、若しくは、優先度の低いバックログ・アイテムにしかならないと思います。
＜参考＞
Open COBOL Solution WG
DDDに関して思った事（難し過ぎるとOOADの二の舞になるよ。的な話）。
