.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

目次

概要

最小構成の依存性反転原則を多層に適用している。

詳細

メリット・デメリット

メリット

これにより、

  • コア・ロジックは
  • 外部インターフェイス(UI、DB等)に

依存しないようにできる。

デメリット

  • なんでもかんでも抽象化するとコードが 複雑化し、混沌となる
  • 抽象度を上げる時は、必ず必要最小限にすること

などを超えている感があるのと、

  • ホントにコンパチのシナリオはあり得るのか?
    • 疑問と言えば疑問。
    • ただし、コンパチ・シナリオの可能性は増えつつある。
      • RDB、NoSQL、WebAPI
      • エンジニアリングの配管工化

利用シーン

以下のようなユースケースでハマりそう。

  • EAI/ETL系のデータフロー・オーケストレーションを実行する
    プロダクト(Apache NiFiのような)ではなく、フレームワーク。
  • デファクトのフレームワークに
    御呪いを書くと繋がる系(ASP.NET の Startup.cs)
  • 以下の段階があり、どの段階が適合するか、よく検討する必要がある。

構成要素

Controller

外部インターフェイス(UI)

  • MVCのController
  • ユーザの入力を解釈し、UseCaseにそれを伝える。

UseCase? + Interactor

コア・ロジック

  • MVCでServiceManager?とも呼ばれる。
  • UseCase?がインターフェイスで、Interactorが実装。
  • DIにより、Controllerから呼び出される。

Repository

外部インターフェイス(DB)

  • Storeとも呼ばれ、データ・アクセスをする。
  • 同様にインターフェイスと実装に分かれる。
  • DIにより、Interactorから呼び出される。

Presenter

外部インターフェイス(UI⇔DB)間の情報伝達を行う。

  • MVCのViewModel?を生成する。
  • 同様にインターフェイスと実装に分かれる。
  • DIにより、Interactorから呼び出される。

ドメイン駆動設計(DDD)

正直、微妙(実践が難しい)かなと。

概要

高位の概念と実践について多数述べられている。

  • 複雑なドメインの設計は、モデルベースで行うべき
  • 大半のソフトウェアプロジェクトでは、
    • システムを実装するための特定の技術ではなく、
    • ドメインそのものとドメインのロジックに焦点を置くべき。

参考

参考

OSSコンソーシアム


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2020-07-22 (水) 19:19:01 (62d)