タグ付けされた質問 「onion-architecture」

クリーンアーキテクチャユースケースをさせインタラクタ応答/表示を処理するために（DIP以下、注入される）プレゼンタの実際の実装を呼び出すことを示唆しています。ただし、このアーキテクチャを実装し、インタラクターから出力データを返し、コントローラー（アダプター層内）がその処理方法を決定できるようにする人がいます。2番目のソリューションは、インタラクターへの入力ポートと出力ポートを明確に定義していないことに加えて、アプリケーションの責任をアプリケーション層から漏えいさせていますか？ 入出力ポート Clean Architectureの定義、特にコントローラー、ユースケースインタラクター、プレゼンター間の関係を説明する小さなフロー図を考慮すると、「ユースケースの出力ポート」がどうあるべきかを正しく理解しているかどうかはわかりません。 六角形アーキテクチャのようなクリーンアーキテクチャは、プライマリポート（メソッド）とセカンダリポート（アダプタによって実装されるインターフェイス）を区別します。通信フローに従って、「ユースケース入力ポート」がプライマリポート（したがって、単なるメソッド）になり、「ユースケース出力ポート」が実装されるインターフェイスになります。実際のアダプターを取得するコンストラクター引数、インタラクターが使用できるようにします。 コード例 コード例を作成するために、これはコントローラーコードになります。 Presenter presenter = new Presenter(); Repository repository = new Repository(); UseCase useCase = new UseCase(presenter, repository); useCase->doSomething(); プレゼンターインターフェイス： // Use Case Output Port interface Presenter { public void present(Data data); } 最後に、インタラクター自体： class UseCase { private Repository repository; private Presenter presenter; public UseCase(Repository …

42 architecture  architectural-patterns  onion-architecture 

BLがCRUDを実行するためにDAL（またはDALのインターフェース）のメソッドを呼び出す責任を負った3層アーキテクチャーよりも、オニオンアーキテクチャーにのみ利点があると思います。タマネギは、関心事、テスト容易性、保守容易性のより良い分離があり、よりきれいです。 だから、オニオンアーキテクチャはすべての面で本当に優れており、3層アーキテクチャは物事を行うための古い方法にすぎません。または、3層アーキテクチャを使用したい場合、いくつかのシナリオがあります。

11 design  architecture  layers  n-tier  onion-architecture 

あなたは会社を追跡するシステムを構築しています。これらの企業には連絡先があります。これらの連絡先は、請求/支払い、販売、注文、カスタマーサポートなど、特定の種類の質問にのみ回答する専門家であることがよくあります。 ドメイン駆動設計とオニオンアーキテクチャを使用して、これを次のタイプでモデル化しました。 会社 連絡先あり 連絡先 連絡先タイプがあります ContactType（列挙型） CompanyRepository（インターフェース） EFCompanyRepository（外部アセンブリで定義、EntityFrameworkを使用、CompanyRepositoryを実装） 私たちのチームは、このアプリケーションのデータベースをモデル化する方法について意見が分かれています。 サイドA：リーンDDDers： 連絡先に有効なContactTypeを定義するのはドメインの仕事です。不明なContactTypesが保存されていないことを検証するためにデータベースにテーブルを追加することは、リークのあるドメインの兆候です。ロジックが広すぎます。 静的テーブルをデータベースと対応するコードに追加することは無駄です。このアプリケーションでは、データベースが1つの問題を解決します。問題を永続化し、それを私に返します。追加のテーブルと対応するCRUDコードを書くのは無駄です。 永続化の戦略を変更することは可能な限り簡単でなければなりません。そのビジネスルールを変更する可能性が高くなります。SQL Serverのコストが高すぎると判断した場合、スキーマに入力したすべての検証を再構築する必要はありません。 サイドB：伝統主義者[それはおそらく公平な名前ではありません。DBCentrists？]： コードを読み取らなければ意味のないデータをデータベースに置くことは悪い考えです。レポートやその他の消費者は、値のリスト自体を繰り返す必要があります。 オンデマンドでdbタイプの辞書をロードするためのコードはそれほど多くありません。心配しないでください。 このソースがデータではなくコードである場合、変更時に単純なSQLスクリプトではなくビットを展開する必要があります。 どちらも正しいか間違っているかではありませんが、そのうちの1つはおそらく長期的にはより効率的であり、初期開発、バグなどの開発時間を数えます。このスタイルのコードを書く他のチームは何をしますか？

10 domain-driven-design  domain-model  onion-architecture 

シナリオ： 顧客が注文し、製品を受け取った後、注文プロセスに関するフィードバックを提供します。 次の集計ルートを想定します。 お客様 注文 フィードバック ビジネスルールは次のとおりです。 顧客は自分の注文についてのみフィードバックを提供でき、他の人のフィードバックは提供できません。 顧客は、注文に対する支払いが済んでいる場合にのみフィードバックを提供できます。 class Feedback { public function __construct($feedbackId, Customer $customer, Order $order, $content) { if ($customer->customerId() != $order->customerId()) { // Error } if (!$order->isPaid()) { // Error } $this->feedbackId = $feedbackId; $this->customerId = $customerId; $this->orderId = $orderId; $this->content = $content; } } ここで、企業が新しいルールを望んでいると想定します。 …

8 domain-driven-design  validation  cqrs  command-message  onion-architecture