開発基盤部会 Blog

開発基盤部会 Blog
12345
2019/11/15new

DDDに関して思った事(難し過ぎるとOOADの二の舞になるよ。的な話)。

Tweet ThisSend to Facebook | by:nishino
 最近、「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は、より大規模なアプリケーション開発で導入されるべき設計で、

 「システムを実装するための特定の技術ではなく、ドメインそのものとドメインのロジックに焦点を置くべき

 といった高位の概念と実践について多数述べられているらしく、なんか、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層を差し替えることは、ホボ、無かったですね。


 従って、実際やろうとすると、レアケースにどれだけ投資するのか?みたいな問題が、必ず浮上してくると思います。そこで決定打が無いと、基本的には優先度が下がって、採用されないプロジェクト、若しくは、優先度最低のバックログ・アイテムと成り得ると思います。
09:00 | 投票する | 投票数(0) | コメント(0) | ご報告
12345