![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
「[[.NET 開発基盤部会 Wiki>http://dotnetdevelopmentinfrastructure.osscons.jp]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。 -[[戻る>依存性反転原則]] *目次 [#l88da091] #contents *概要 [#z3bf9209] [[最小構成の依存性反転原則>依存性反転原則#ecda4880]]を多層に適用している。 *詳細 [#r787552c] コア・ロジックは外部I/Oインターフェイス（UI、DB等）を使用する際、 -インターフェイス経由で利用することで、コンパチ可能に実装する。 -[[DI>依存性反転原則#g8343c51]]により、インターフェイスを継承したインスタンスが設定される。 **メリット・デメリット [#i3942654] ***メリット [#zbf80ba5] これにより、 -コア・ロジックは -外部I/Oインターフェイス（UI、DB等）に 依存しないようにできる。 ***デメリット [#gc0a10ca] -[[依存性反転原則]]の注意事項にあった --なんでもかんでも抽象化するとコードが 複雑化し、混沌となる --抽象度を上げる時は、必ず必要最小限にすること >などを超えている感があるのと、 -ホントにコンパチのシナリオはあり得るのか？ --疑問と言えば疑問。 --ただし、コンパチ・シナリオの可能性は増えつつある。 ---RDB、NoSQL、WebAPI ---エンジニアリングの[[配管工化>https://www.google.com/search?q=site%3Aosscons.jp+%E9%85%8D%E7%AE%A1%E5%B7%A5]] -以下はMVCの例だが、DesktopやFrontend系では、また別途検討が必要になる。 -MVC系の例が多いが、DesktopやFrontend系では、また別途検討が必要になる。 ***利用シーン [#g2119f30] 以下のようなユースケースでハマりそう。 -EAI/ETL系のデータフロー・オーケストレーションを実行する~ プロダクト（[[Apache NiFi]]のような）ではなく、フレームワーク。 -デファクトのフレームワークに~ 御呪いを書くと繋がる系（ASP.NET の Startup.cs） -以下の段階があり、どの段階が適合するか、よく検討する必要がある。 --ラッパー --[[DI + IoC>依存性反転原則#w42dcdfc]] --[[依存性反転原則]] --クリーン・アーキテクチャ **構成要素 [#r19a19fe] ***Controller [#m1c9b02b] 外部I/Oインターフェイス（UI） -MVCのController -ユーザの入力を解釈し、[[UseCase>#a0aa4dfe]]にそれを伝える。 ***UseCase + Interactor [#a0aa4dfe] コア・ロジック -MVCでServiceManagerとも呼ばれる。 -UseCaseがインターフェイスで、Interactorが実装。 -[[DI>依存性反転原則#g8343c51]]により、[[Controller>#bc3fe389]]から呼び出される。 -コア・ロジックであるInteractorは、 --[[Repository>#y2e4ef36]] --[[Presenter>#k0ebeaab]] >などの外部I/Oインターフェイスを呼び出す。 ***Repository [#y2e4ef36] 外部I/Oインターフェイス（DB） -Storeとも呼ばれ、データ・アクセスをする。 -[[同様>#a0aa4dfe]]にインターフェイスと実装に分かれる。 -[[DI>依存性反転原則#g8343c51]]により、[[Interactor>#a0aa4dfe]]から呼び出される。 ***Presenter [#k0ebeaab] 外部I/Oインターフェイス（UI⇔DB）間の情報伝達を行う。 -MVCのViewModelを生成する。 -[[同様>#a0aa4dfe]]にインターフェイスと実装に分かれる。 -[[DI>依存性反転原則#g8343c51]]により、[[Interactor>#a0aa4dfe]]から呼び出される。 **ドメイン駆動設計（DDD） [#h6ae72f7] 正直、微妙（実践が難しい）かなと。 ***概要 [#v78536e5] 高位の概念と実践について多数述べられている。 -複雑なドメインの設計は、モデルベースで行うべき -大半のソフトウェアプロジェクトでは、 --システムを実装するための特定の技術ではなく、 --ドメインそのものとドメインのロジックに焦点を置くべき。 ***参考 [#vf91d6c3] -ドメイン駆動設計 - Wikipedia~ https://ja.wikipedia.org/wiki/%E3%83%89%E3%83%A1%E3%82%A4%E3%83%B3%E9%A7%86%E5%8B%95%E8%A8%AD%E8%A8%88 *参考 [#j9329152] -世界一わかりやすいClean Architecture - nuits.jp blog~ https://www.nuits.jp/entry/easiest-clean-architecture-2019-09 **Qiita [#nc8f6a2f] -実装クリーンアーキテクチャ~ https://qiita.com/nrslib/items/a5f902c4defc83bd46b8 -フロントエンドでClean Architectureを適用してみる(+サンプルコード)~ https://qiita.com/ttiger55/items/50d88e9dbf3039d7ab66 **OSSコンソーシアム [#tec78158] ***開発基盤部会 Blog [#o740357a] -DDDに関して思った事（難し過ぎるとOOADの二の舞になるよ。的な話）。~ https://www.osscons.jp/jok7exzd5-537/ >https://twitter.com/openhishopjpo/status/1237548569696985088 -色々考え、汎用認証サイトのクリーン・アーキテクチャを放棄した件~ https://www.osscons.jp/jobvap48p-537/ >https://twitter.com/openhishopjpo/status/1284107881344757761
