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

私が管理している新しいチームでは、コードの大部分はプラットフォーム、TCPソケット、およびhttpネットワークコードです。すべてのC ++。その大部分は、チームを去った他の開発者からのものです。チームの現在の開発者は非常に賢いですが、ほとんどの場合、経験的には後輩です。 私たちの最大の問題：マルチスレッドの同時実行バグ。ほとんどのクラスライブラリは、いくつかのスレッドプールクラスを使用して非同期に作成されています。クラスライブラリのメソッドは、長時間実行されるタスクを1つのスレッドからスレッドプールにキューイングすることが多く、そのクラスのコールバックメソッドは別のスレッドで呼び出されます。その結果、誤ったスレッドの仮定に関連する多くのエッジケースバグがあります。これにより、同時実行性の問題から保護するための重要なセクションとロックを保持するだけでなく、微妙なバグが発生します。 これらの問題をさらに困難にしているのは、修正の試みがしばしば間違っていることです。チームが（またはレガシーコード自体で）試みようとしているミスには、次のようなものがあります。 よくある間違い＃1-共有データをロックするだけで同時実行の問題を修正しますが、メソッドが期待される順序で呼び出されない場合に何が起こるかを忘れます。これは非常に簡単な例です： void Foo::OnHttpRequestComplete(statuscode status) { m_pBar->DoSomethingImportant(status); } void Foo::Shutdown() { m_pBar->Cleanup(); delete m_pBar; m_pBar=nullptr; } そのため、OnHttpNetworkRequestCompleteの実行中にShutdownを呼び出すことができるバグがあります。テスターはバグを見つけ、クラッシュダンプをキャプチャし、バグを開発者に割り当てます。彼は次のようにバグを修正します。 void Foo::OnHttpRequestComplete(statuscode status) { AutoLock lock(m_cs); m_pBar->DoSomethingImportant(status); } void Foo::Shutdown() { AutoLock lock(m_cs); m_pBar->Cleanup(); delete m_pBar; m_pBar=nullptr; } 上記の修正は、さらに微妙なエッジケースがあることに気付くまでは問題ありません。OnHttpRequestCompleteがコールバックされる前にシャットダウンが呼び出されるとどうなりますか？私のチームが持っている実際の例はさらに複雑であり、コードレビュープロセス中にエッジケースを見つけるのはさらに困難です。 よくある間違い＃2-盲目的にロックを終了し、他のスレッドが終了するのを待ってからロックを再入力することで、デッドロックの問題を修正します。 よくある間違い＃3-オブジェクトは参照カウントされますが、シャットダウンシーケンスはポインターを「解放」します。しかし、まだ実行中のスレッドがそのインスタンスを解放するのを待つことを忘れています。そのため、コンポーネントは完全にシャットダウンされ、その後、コールを予期しない状態のオブジェクトでスプリアスまたはレイトコールバックが呼び出されます。 他のエッジケースもありますが、一番下の行はこれです： マルチスレッドプログラミングは、頭のいい人でも簡単です。 これらの間違いを見つけると、より適切な修正を開発するために各開発者とエラーについて話し合うことに時間を費やします。しかし、「正しい」修正には触れなければならない膨大な量のレガシコードのため、各問題の解決方法についてしばしば混乱していると思われます。 私たちはすぐに出荷するつもりであり、私たちが適用しているパッチは今後のリリースに適用されると確信しています。その後、コードベースを改善し、必要に応じてリファクタリングする時間があります。すべてを書き直す時間はありません。そして、コードの大部分はそれほど悪くはありません。しかし、スレッドの問題を完全に回避できるように、コードをリファクタリングしたいと考えています。 私が検討しているアプローチの1つはこれです。重要なプラットフォーム機能ごとに、すべてのイベントとネットワークコールバックがマーシャリングされる専用の単一スレッドを用意します。メッセージループを使用したWindowsでのCOMアパートメントスレッドに似ています。長時間のブロッキング操作はワークプールスレッドにディスパッチされる可能性がありますが、コンポーネントのスレッドで完了コールバックが呼び出されます。コンポーネントは同じスレッドを共有することさえできます。その後、スレッド内で実行されるすべてのクラスライブラリは、単一のスレッド化された世界を想定して記述できます。 その道を進む前に、マルチスレッドの問題に対処するための他の標準的な手法や設計パターンがあるかどうかにも非常に興味があります。そして、私は強調しなければなりません-ミューテックスとセマフォの基本を説明する本を超えた何か。どう思いますか？ また、リファクタリングプロセスに向けた他のアプローチにも興味があります。次のいずれかを含む： スレッド周辺のデザインパターンに関する文献または論文。ミューテックスとセマフォの紹介を超えたもの。大規模な並列処理も必要ありません。他のスレッドからの非同期イベントを正しく処理するようにオブジェクトモデルを設計する方法だけです。 さまざまなコンポーネントのスレッド化を図式化する方法。これにより、ソリューションの研究と発展が容易になります。（つまり、オブジェクトおよびクラス全体のスレッドを議論するためのUML同等物） …

26 design  c++  architecture  multithreading 

モノリシックREST APIをマイクロサービスアーキテクチャに移行することを検討していますが、データストレージについて少し混乱しています。私が見るように、マイクロサービスの利点のいくつかは次のとおりです。 水平方向にスケーラブル-負荷やサーバーのダウンに対処するために、マイクロサービスの複数の冗長コピーを実行できます。 疎結合-他のマイクロサービスを変更することなく、マイクロサービスの内部実装を変更できます。また、独立して展開および変更することもできます。 私の問題はデータストレージです。ご覧のとおり、いくつかのオプションがあります。 すべてのマイクロサービスで共有される単一のデータベースサービス-これは、疎結合の利点を完全に排除するようです。 各マイクロサービスにローカルにインストールされたデータベースインスタンス-これを水平方向にスケーリングする方法が見当たらないため、オプションとは思わない。 各マイクロサービスには独自のデータベースサービスがあります-疎結合と水平スケーリングの利点を保持するため、これは最も有望であると思われます（冗長データベースコピーの使用および/または複数でのシャーディング） 私には、3番目のオプションが唯一のオプションのように思えますが、私には信じられないほど重く、非常に過剰に設計されたソリューションです。私がそれを正しく理解している場合、4-5マイクロサービスを備えたシンプルなアプリケーションでは、16-20サーバーを実行する必要があります-マイクロサービスごとに2つの実際のマイクロサービスインスタンス（サーバー障害の場合、およびダウンタイムなしでデプロイするため）、およびマイクロサービスごとに2つのデータベースサービスインスタンス（サーバー障害などの場合）。 これは、率直に言って、少しばかげているようです。16〜20台のサーバーでシンプルなAPIを実行しますが、現実的なプロジェクトにはおそらく4〜5以上のサービスがあることに留意してください。これを説明する基本的な概念がありませんか？ 回答中に役立ついくつかのこと： 私はこのプロジェクトの唯一の開発者であり、近い将来になります。 Node.jsとMongoDBを使用していますが、言語に依存しない回答に興味があります。答えは、間違ったテクノロジを使用しているだけかもしれません。

25 architecture  rest  api-design  microservices 

職場やオンラインでビジネスロジックについて多くの人が話しているのを聞いたことがあり、このサイトに関するいくつかの質問を読んだことがありますが、この用語はまだあまり意味がありません。たとえば、私がよく見かける（言い換え）ステートメントは次のとおりです。 「ビジネスロジックは、実際のビジネスルールをエンコードするプログラムの一部です。」私が読んだ定義のほとんどは、このような円形のものです。 「ビジネスロジックは、特定のアプリケーションに固有のすべてです。」「特定のアプリケーションはビジネスロジック以外の何物でもない」と、これがどのように異なるかはわかりません。したがって、質問のタイトル。 「データアクセス層の上とGUI層の下にビジネスロジック層が必要です。」私が書いたコードでは、データベースアクセサーはアクセスするデータを知る必要があり、UIコードはそれを正しく表示するために表示するものについて多くを知る必要があり、その間に実際に行うことは何もありませんクライアントとサーバー間でデータの塊を渡すこと以外の2つの場所。それでは、実際にビジネスロジックレイヤーに入るものは何でしょうか？ 「ビジネスロジックはプレゼンテーションロジックから分離する必要があります。」私たちが受け取る機能要求のほとんどは、ビジネス上の理由でプレゼンテーションロジックを変更することです。ビジネスルールの1つが、デフォルトで32番目の表記で米国国債の価格を表示する場合（ユーザーに構成するためのUIも提供します）、プレゼンテーションロジックは、このルールが完全に実装されていない場合、少なくとも存在することを知る必要があります。また、UXデザインの主要な部分は、ユーザーがソフトウェアが実装しようとしているビジネスルールを理解するのを支援しているようです。 実際にビジネスロジックのみを行うチームに所属していて、非ビジネスロジックはすべて他のチームによって実行されている可能性はありますか？または、個別のエンティティとしての「ビジネスロジック」の概念全体は、特定のアプリケーションまたはアーキテクチャでのみ機能しますか？ 答えを具体的にするために：ドミノのピザアプリを再実装する必要があると仮定します。ビジネスロジックとは何ですか？また、そのアプリの非ビジネスロジックとは何ですか？そして、ピザ情報のほとんどがデータアクセス層とプレゼンテーション層に流出することなく、ピザの注文ビジネスロジックを独自のコードの「層」に配置するにはどうすればよいでしょうか。 更新：私のチームはおそらく90％のUIコードを実行しており、ビジネスロジックと呼ばれるものの大部分（すべてではない）が他のチームまたは企業から来ているという結論に達しました。基本的に、私たちのアプリケーションは監視用です財務データ、およびほとんどすべての機能は、ユーザーが表示するデータと表示方法をカスタマイズする方法です。売買は行われていません（ただし、当社の他のアプリと少し統合しています）が、実際のデータは外部ソースの負荷によって提供されます。しかし、ユーザーは自分の「モニター」のコピーを他のユーザーに送信するなどのことを許可しているので、私たちがそれをどのように処理するかの詳細は、おそらくビジネスロジックとみなされます。実際には、現在バックエンドコードの一部と通信するモバイルアプリがあり、フロントエンドコードのどの部分を理想的な世界（基本的には準MVCのM）でUIと共有したいかを正確に知っています。それが私たちにとってのBLLだと思います。 user61852の答えは、「ビジネスロジック」が何を参照し、何を参照していないかについて、より具体的な理解を与えてくれたので受け入れています。

25 architecture  business-logic  business-rules 

ほとんどすべての状況で、主キーはビジネスドメインの一部ではありません。確かに、一意のインデックスを持つユーザー向けの重要なオブジェクト（UserNameユーザーまたはOrderNumber注文用）がいくつかある場合もありますが、ほとんどの場合、1つまたは複数の値によってドメインオブジェクトを明確に識別する必要はありません管理ユーザー。これらの例外的な場合でも、特にグローバル一意識別子（GUID）を使用している場合は、主キー自体を公開するのではなく、代替キーを使用したい、または使用したいでしょう。 したがって、ドメイン駆動型設計の私の理解が正確である場合、主キーを公開する必要はなく、したがって公開すべきではありません。彼らはくて、私のスタイルをcr屈にします。しかし、ドメインモデルに主キーを含めないことを選択した場合、結果が生じます。 単純に、ドメインモデルの組み合わせから排他的に派生するデータ転送オブジェクト（DTO）には主キーがありません 着信DTOには主キーはありません したがって、ドメインモデルで本当に純粋でプライマリキーを削除する場合、そのプライマリキーの一意のインデックスに関してすべての要求を処理できるように準備する必要があると言っても安全ですか？ 別の言い方をすれば、ドメインモデルでPKを削除した後に特定のオブジェクトを識別するための正しいアプローチは、次のソリューションのどれですか 他の属性で処理する必要があるオブジェクトを識別できること DTOで主キーを取得します。つまり、永続性からドメインへのマッピング時にPKを削除し、ドメインからDTOへのマッピング時にPKを再結合しますか？ 編集：これを具体的にしましょう。 私のドメインモデルがあると言うVoIPProviderなどの分野が含まれName、Description、URL、などのような参照ProviderType、PhysicalAddressおよびを、Transactions。 ここで、特権ユーザーがVoIPProviders を管理できるWebサービスを構築したいとします。 おそらく、この場合、ユーザーフレンドリーなIDは役に立ちません。結局のところ、VoIPプロバイダーは、コンピューターの意味で名前が明確になり、ビジネス上の理由から人間の意味でも十分に区別される傾向がある企業です。それで、ユニークVoIPProviderは完全に決定されると言うことで十分かもしれません(Name, URL)。PUT api/providers/voip特権ユーザーがVoIPプロバイダーを更新できるようにする方法が必要だとしましょう。は、を送信しますVoIPProviderDTO。これには、からのすべてのフィールドではなく、多くのフィールドが含まれVoIPProviderます。しかし、私は彼らの心を読むことができず、彼らはまだ私たちが話しているプロバイダーを教えてくれる必要があります。 私は2つ（おそらく3つ）のオプションを持っているようです： ドメインモデルにプライマリキーまたは代替キーを含めてDTOに送信します。逆も同様です。 次のような一意のインデックスを使用して、関心のあるプロバイダーを特定します。 (Name, Url) 永続層に関する実装の詳細を公開しない方法で、永続層、ドメイン、およびDTOの間を常にマッピングできる何らかの中間オブジェクトを導入します。たとえば、ドメインからDTOに移動するときにメモリ内の一時識別子を導入し、

25 architecture 

モバイルアプリケーションを開発したい。最近、Telerik Forumの記事を読みました。この記事では、3種類のモバイルアプリケーションを比較していますが、どちらを選択すればよいかわかりません。以下は、さまざまなモバイルデザインの選択の長所と短所を説明する画像です。 これらの設計の選択を決定するために、図にリストされている各アーキテクチャの選択の長所と短所をよりよく理解したいと思います。各アーキテクチャアプローチの長所と短所は何ですか？

25 design  architecture  programming-practices  mobile 

シングルスレッドアプリケーションの場合、クラス図を使用して、そのアプリケーションのアーキテクチャの概要を取得します。ただし、このタイプのダイアグラムは、たとえば、異なるスレッドでクラスの異なるインスタンスが「ライブ」であるため、重いマルチスレッド/同時実行アプリケーションを理解しようとするときにはあまり役に立ちません（つまり、インスタンスへのアクセスは、それが住んでいるスレッド）。したがって、クラス間の関連付けは、必ずしもそれらのオブジェクトのメソッドを呼び出すことができるという意味ではありませんが、代わりにターゲットオブジェクトのスレッドで呼び出しを行う必要があります。 Hassan GomaaによるUMLを使用した並行、分散、およびリアルタイムアプリケーションの設計などのトピックについて掘り下げたほとんどの文献には 、スレッド境界をオブジェクト図に描画するなどの素晴らしいアイデアがありましたが、本当に便利です。 これらの図を問題ドメインの高レベルのビューとして使用するのではなく、クラス/オブジェクト、それらの相互作用、および前述のスレッド境界による制限の詳細な説明として使用します。 したがって、私は知りたい： マルチスレッドアプリケーションの理解に最も役立つとわかったのは、どのような種類の図ですか？ マルチスレッドアプリケーションの特性を考慮したクラシックUMLの拡張機能はありますか。たとえば、 一部のオブジェクトは特定のスレッドに存在し、他のオブジェクトはスレッドアフィニティを持たない場合があります。 オブジェクトの一部のフィールドは、任意のスレッドから読み取ることができますが、1つのスレッドからのみ書き込むことができます。 いくつかのメソッドは同期して結果を返しますが、他のメソッドはリクエストをキューに入れて、たとえば異なるスレッドのコールバックを介して結果を返す非同期です。

25 architecture  uml  multithreading  concurrency 

MVCパターンを使用するために開発したWebアプリケーションを再構築しようとしていますが、検証をモデルで処理すべきかどうかはわかりません。たとえば、次のようにモデルの1つを設定しています。 class AM_Products extends AM_Object { public function save( $new_data = array() ) { // Save code } } 最初の質問：では、saveメソッドが$ new_dataの検証関数を呼び出すべきか、データが既に検証されていると仮定するのか疑問に思っていますか？ また、検証を提供する場合、データ型を定義するモデルコードの一部は次のようになると考えています。 class AM_Products extends AM_Object { protected function init() // Called by __construct in AM_Object { // This would match up to the database column `age` register_property( 'age', 'Age', …

25 architecture  mvc 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 6年前に閉鎖されました。 ロックされています。この質問とその回答はロックされています。なぜなら、質問はトピックから外れていますが、歴史的に重要だからです。現在、新しい回答やインタラクションを受け入れていません。 図をどこかに保存して後で編集できるようにする必要がある場合、ほとんどの設計/建築作業にMS Visioを使用します。私はVisioの最大のファンではありませんが、仕事を終わらせます（仕事中は無料です）。 かなり高価なVisioソフトウェアに代わる優れた代替品があり、おそらくもっと良いものがありますか。私は確かにツールボックスにそのプログラムを持ちたいです！

25 design  architecture  visio 

LMAXのチームがJavaでLMAX Disruptorを設計したのに、GCの使用を最小限に抑えることがすべての設計ポイントであるのはなぜですか？GCを実行したくない場合、ガベージコレクションされた言語を使用するのはなぜですか？ 彼らの最適化、ハードウェアの知識のレベル、そして彼らが置いた思考はただ素晴らしいですが、なぜJavaなのでしょうか？ 私はJavaなどに反対ではありませんが、なぜGC言語なのですか？DのようなものやGCを使用しない他の言語を使用して、効率的なコードを使用できるのはなぜですか？チームはJavaに最も精通しているのでしょうか、それともJavaには私には見られない独自の利点がありますか？ 手動のメモリ管理でDを使用して開発するとしますが、違いは何でしょうか？低レベル（既にある）を考える必要がありますが、システムがネイティブであるため、システムから最高のパフォーマンスを引き出すことができます。

24 java  architecture  performance  garbage-collection  d 

次の場合に教えてください： Node.jsを使用するとサイトが高速になります！ Node.jsはより少ないサーバーリソースを消費するため、コストを節約できます！ Node.jsにより生産性が向上します！ Node.jsは、クライアント側とサーバー側のJavaScriptコードを共有できることを意味します。 明確にするために、フロントエンドサーバーを書き換えています。これは、既存のRuby on RailsアプリケーションとAPIとして対話します。その間、Ruby on Railsアプリケーションをサービスにリファクタリングします。 既存のアーキテクチャの詳細： HTMLパーシャルキャッシュ用のMemcached セッション用のRedis、および構造化されたデータキャッシング MySQLシングルマスター、マルチスレーブ 多数の書き込みを受け入れる1つの大きなテーブルがあります（ポーリングを想像してください） それ以外の場合はほとんど読み取ります。 一部のメタデータ用のMongoDB Ruby on Rails 3.0 nginxとUnicorn

24 architecture  ruby-on-rails  node.js  rewrite 

Apple AppStoreやGoogle Playアプリストアなどのアプリケーション（ネイティブまたはWeb）を構築するとき、Model-View-Controllerアーキテクチャを使用することは非常に一般的であることを知っています。 ただし、ゲームエンジンで一般的なComponent-Entity-Systemアーキテクチャを使用してアプリケーションを作成することは合理的ですか？

24 design-patterns  architecture  mvc  game-development  applications 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 最近、私はMVCとそれがウェブに合わないことに関するいくつかのブログ投稿を読んでいました。RMR Architectureのような代替パターンについて学びました。 MVCのほかに、人々がWebで使用している他のパターンに興味がありますか？また、パターンを実装するフレームワークがある場合は、そのリンクを投稿してください。

24 design-patterns  architecture  mvc 

通常、サーバー側のコントローラーに承認の決定を下します。これらは最近RESTfulエンドポイントになりましたが、MVCタイプのアーキテクチャも同じものだと思います。議論のために、それは役割ベースの承認であると仮定します。保護されたメソッドには注釈が付けられるか、チェックが行われ、必要に応じて403が返されます。 さて、承認が実際にはビジネスルールであることを考えると、たとえば「管理者だけがXをリストできる」ということを考えると、私は彼らがレイヤーを押し下げられるべきだと考えています。コントローラーがビジネスレイヤーに操作の実行を要求すると、サービスまたはビジネスレイヤーは、コントローラーに許可されていないことを通知します。 これは合理的なアプローチですか？これには欠点はありますか？ これを行うための静的な手続き型のコード化されたルールを本質的に保持するAuthorisationServiceがあるのは嫌ですが、すべてのアクセスロジックを1か所に保持することは理にかなっています。それは別々に保たれるべき横断的な関心事ですか？ だから私は誰かがこれをやったかどうか、彼らがそれをどのようにきれいに達成したか、または私が読むことができる良いリソースがあるかどうかを尋ねています。Java fwiwを使用していますが、これは言語に依存しない質問です。 ここで関連する質問を確認しましたが、それらは非常に薄いので、答えはありません。例：ドメインモデルでの検証と承認、およびサービスレイヤーを介したMVCへの実行 私は春のセキュリティ文書を読んでいますが、それは横断的な関心事であるといくつかの良い議論をしていますが、それは単なる「春の道」であり、より広い視野が欲しいと心配しています。また、アプリケーションを特定のフレームワークに結び付けます。

24 architecture 

ORMを切り替える必要がありましたが、クエリロジックが至る所でリークしていたため、それは比較的困難な作業でした。新しいアプリケーションを開発する必要があった場合、個人的な好みは、すべてのクエリロジックを（ORMを使用して）カプセル化して、変更に対する将来性を保証することです。リポジトリパターンはコーディングと保守が非常に面倒なので、問題を解決する他のパターンがあるかどうか疑問に思っていましたか？ 実際に必要になる前に余分な複雑さを追加しないこと、アジャイルであることなどについての投稿を予見できますが、私は既存のパターンが同様の問題をより簡単な方法で解決することにのみ興味があります。 私が最初に考えたのは、必要に応じて拡張メソッドを介して特定のタイプリポジトリクラスにメソッドを追加する汎用タイプリポジトリを使用することでしたが、静的メソッドのユニットテストは非常に苦痛です。IE： public static class PersonExtensions { public static IEnumerable<Person> GetRetiredPeople(this IRepository<Person> personRep) { // logic } }

24 .net  architecture 

Webアプリケーションがあります。テクノロジーが重要だとは思わない。構造は、左の画像に示されているN層アプリケーションです。3つの層があります。 UI（MVCパターン）、ビジネスロジックレイヤー（BLL）およびデータアクセスレイヤー（DAL） 私が抱えている問題は、ロジックとアプリケーションイベントコールを介したパスがあるため、BLLが非常に大きいことです。 アプリケーションの一般的なフローは次のとおりです。 UIで発生したイベントは、BLLのメソッドにトラバースし、ロジック（おそらくBLLの複数の部分で）を実行し、最終的にDALに戻り、BLLに戻り（さらにロジックが高い場合）、UIに値を返します。 この例のBLLは非常に忙しいため、これを分割する方法を考えています。また、ロジックとオブジェクトが組み合わされており、それらは好きではありません。 右側のバージョンは私の努力です。 ロジックは依然としてアプリケーションがUIとDALの間を流れる方法ですが、おそらくプロパティはありません...メソッドのみ（このレイヤーのクラスの大部分は、状態を格納しないため、静的である可能性があります）。Pocoレイヤーは、プロパティ（名前、年齢、身長などが存在するPersonクラスなど）を持つクラスが存在する場所です。これらはアプリケーションのフローとは関係なく、状態のみを保存します。 フローは次のとおりです。 UIからトリガーされ、UIレイヤーコントローラー（MVC）にデータを渡します。これにより、生データが変換され、pocoモデルに変換されます。その後、pocoモデルはLogicレイヤー（BLL）に渡され、最終的には途中で操作される可能性のあるコマンドクエリレイヤーに渡されます。コマンドクエリレイヤーは、POCOをデータベースオブジェクトに変換します（ほぼ同じものですが、1つは永続化用に設計され、もう1つはフロントエンド用に設計されています）。アイテムが保存され、データベースオブジェクトがコマンドクエリレイヤーに返されます。その後、POCOに変換され、そこでロジックレイヤーに戻り、さらに処理され、最後にUIに戻される可能性があります 共有ロジックとインターフェイスは、MaxNumberOf_XやTotalAllowed_Xなどの永続データとすべてのインターフェイスを保持する場所です。 共有ロジック/インターフェイスとDALの両方が、アーキテクチャの「ベース」です。これらは外の世界について何も知りません。 共有ロジック/インターフェースとDAL以外のすべてがpocoについて知っています。 フローはまだ最初の例と非常によく似ていますが、各レイヤーが1つのこと（状態、フロー、その他）に責任を負います...しかし、このアプローチでOOPを壊していますか？ LogicとPocoをデモする例は次のとおりです。 public class LogicClass { private ICommandQueryObject cmdQuery; public PocoA Method1(PocoB pocoB) { return cmdQuery.Save(pocoB); } /*This has no state objects, only ways to communicate with other layers such as the cmdQuery. Everything else is just …

23 object-oriented  architecture