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

最近、私はプログラム開発中に、彼らがアジャイル開発プロセスを使用する場合はこれが正常であると言って、新しい機能と正当化された事に取り組んでいる間、定期的にテーブルとカラムを定期的に作成および削除することを述べた開発者と議論しました。 私のバックグラウンドのほとんどはウォーターフォール開発環境にあるので、これがアジャイル開発で実際に適切であると考えられているのか、またはこれが根本的な問題の兆候であるのか、プログラムアーキテクチャまたはアジャイルプロセスのフォローに関するものなのか疑問に思います。

11 architecture  agile  database 

私はASP.NET MVC（およびその他のWebベースのMVC実装）を頻繁に使用しますが、これは私が確信したことのないことです。コントローラーとビューは通信する必要がありますか？ もちろん、コントローラーは使用するビューを選択する必要がありますが、コントローラーがビューにデータを渡すのはどういうことですか？私の意見では、ビューがコントローラーからのデータを期待している場合、それらは（コントローラー、ビュー）のペアとして効果的に結び付けられています。代わりに、通常、ビューはモデル自体と通信し、コントローラーから独立しています。 私は正しいアプローチを持っていますか、これは誰も正しい答えがない場合ですか？Webで作業するときと他の環境で作業するときの答えは変わりますか？厳密に型指定されたビュー（ASP.NET MVCなど）の概念がある場合、答えは変わりますか？

11 architecture  mvc 

私は、Asp.Netベースの大規模なWebサイトを担当しています。現在、これはWebアプリケーション（Webアプリケーションではない）、一部のWindowsサービス、および多数のクラスライブラリです。 データレイヤーは、LLBLGEN とLinq To LLBGenの混合、およびリファクタリングされていないレガシーインラインSQLのインスタンスを使用します。 マネージャータイプの実装がいくつかありますが、多くの場合、アプリケーションはスマートUIアンチパターンを示します（つまり、クラスの背後にあるコードのビジネスロジックが多すぎる） サイトのトラフィックはかなり高く、パフォーマンスは良好ですが、開発能力を約10人のチームにまで拡大しており、既存のミドルウェアの上に包括的な階層化設計が必要であることがますます明らかになっています。 私の質問はどこから始めればいいですか？私たちには10年のコード（ASP Classicのものを移行したものもあります）、さまざまなアプローチ、スタイルがあります。 コードベース全体のリファクタリングは現実的ではなく、おそらく望ましくありません 私はこれが新しい状況ではないことを知っています、この問題にどのようにアプローチするかに関して有用なアイデアや概念はありますか？

11 architecture  asp.net  legacy 

現在、新しい製品/プロジェクトに取り組んでいます。これは、特定の特定の産業/サービス企業向けのクライアント/サーバーアプリケーションです。Javaフロントエンドを備えたTCP上でカスタムプロトコルを実行するサーバー（C言語およびLinuxのみ）を構築しています。私たちはコーディング作業に約20％取り組んでおり、マイクロカーネルアーキテクチャまたはモノリシックカーネルアーキテクチャを選択する必要がある状況に直面しています。 Micro vs. Monolithicは通常カーネルアーキテクチャに関連していることは承知していますが、具体的にはサーバーについて話しています。 既存のサーバーではなく、カスタムサーバーが必要な理由 UIのニーズは非常に大きく、非常に動的であるため、Web / Webブラウザーベースのソリューションは適切ではありませんでした。 統計処理はクライアント側で重要であるため、ブラウザーもほとんど役に立ちませんでした。（もちろん、サーバー側で処理を実行し、処理されたデータをクライアントに渡すこともできますが、これはサーバーの負荷が大きくなり、クライアントリソースが浪費されることを意味します）。 さらに、少なくとも3つのテクノロジー（JS / HTML / CSS）で1つのイベントを管理することで、砂漠の嵐の中で家を一掃するような全体の体験ができます。 マイクロサーバーとモノリシックサーバーはどうですか？あなたは何をしゃべってますか？ 次の（仮想の）クライアント要求を検討してください。 request-id: 123 request-service: HistoricDataSets request-message: Fetch all records upto the year 2010 そのようなリクエストを受信すると、サーバーは通常、次のことを行います（簡単にするために、スレッドやフォークなどの同時実行技術は無視しています）。 リクエスト文字列を解析する アクションを特定する（HistoricDataSets LIMIT Year (2010)この場合はフェッチ） 永続化レイヤー（この例ではOracle、と言うことができます）と対話して、データをフェッチします。 プロトコルに従ってデータをフォーマットします。例： response-id：123 success：true response-text：DataSets このようにフォーマットされたデータでクライアントに応答します。 これは、モノリシックサーバー（すべてのOSの動作がカーネル空間で行われるモノリシックカーネルに似ています）と呼ばれるものです。 再度、同じリクエストを受け取り、今回はサーバーを考慮します（簡単にするため、共有メモリのみをIPCと仮定しました）。 Parserプロセスの共有メモリに要求を入れます Parserタスクを特定し、文字列を解析し、指示するExecutionerタスクを実行するためのプロセス。 次にExecutioner、Fomatterプロセスにデータを渡し、データをプロトコル文字列にフォーマットした後、サーバーに戻ります。 サーバーはそれをクライアントにディスパッチします（応答）。 もちろん、代わりのParser、ExecutionerそしてFormatterそれは、単一のが、別のプロセスだったかもしれません。これは、私たちがマイクロサーバーと呼んでいるものです（マイクロカーネルが最低限必要なことをやっていることに似ています）。サーバーは実質的にリスニングと応答のみを行いますが、すべてのステップは異なるプロセスによって処理されます。 どれを選ぶべきですか？混乱しています！モノリシックサーバーは試行およびテストされていますが（ほとんどのHTTP-Webサーバー？）、プログラミングが容易であり、同時実行性を非常にうまく処理できます。マイクロサーバーは、一見、迅速で、1つのタスクを実行する1つのプログラムというUNIXの原則に沿っているように見えますが、特に開発が複雑です。並行性を念頭に置いてください。 質問 -各アプローチの長所と短所は何ですか（場合によっては）。 …

11 architecture  server 

本質的に非常にモジュール化された新しいソリューションの設計を検討しており、その設計をサポートする構造を作成して、将来の拡張、懸念の明確な分離、モジュールごとのライセンス付与などを可能にします。 Webで発見されたモジュラーアプリケーションまたは複合アプリケーションはUI中心で、Silverlight、WPFなどに焦点を当てています。私の場合は、さまざまなUIプロジェクトに取り組んでいる他の開発者が使用するWCFサービスアプリケーションを開発しています。 バックグラウンド 私のプロジェクトの目標は、ビジネス/ドメインロジックの一元化されたソースを作成して、現在プロセスやルールなどを複製しているいくつかのビジネスアプリケーションをサポートすることです。また、モジュール性のすべての利点が得られるわけではありませんが、活用できるこれらの部分を活用するフレームワークを確立する機会。 サービスアプリケーションによって公開されるAPIを見て、設計を開始しました。私が検討していたモジュラー回線に沿ってサービスを分離できることは明らかです。たとえば、FinanceService、InventoryService、PersonnelServiceなどのサービスを使用して、サービス操作をグループ化して、APIで高い凝集度を提供し、カップリングを低く抑えて、クライアントがアプリケーションに関連するサービスのみを消費するようにします。 MyApp.Finance、MyApp.Inventory、My.Personnelなど、これらのサービスごとに個別のモジュールを持つことができるのは理にかなっています。横断的関心事と共有タイプは、MyApp共有アセンブリにあります。ここから少し縛られます。 （ああ、アプリケーションの疎結合を維持するためにDependency InjectionにIoCコンテナーを使用することに言及する必要があります。Pandoraのボックスを開きたくないので、どれに言及しません！） MyApp.ServiceHostで、FinanceService.svcなどの各モジュールに対応するサービスホストファイル（.svc）を作成します。サービスホストには、サービスコントラクトを定義するインターフェイスを含む構成ファイルの情報に対応するサービスの名前が必要です。次に、IoC構成を使用して、使用するインターフェイスの具体的な実装をマップします。 1.サービス層はAPIを実装し、モジュールに委任する必要がありますか、またはモジュールは自己完結型である必要があります（サービス実装を含む、そのモジュールに関連するすべてを含むという点で）。 問題にアプローチする1つの方法は、サービスコントラクトの実装を含むMyApp.Services "モジュール"を持つことです。各サービスクラスは、操作のドメインロジックを含む適切なモジュール内の別のクラスに単純に委任します。たとえば、MyApp.ServicesのFinanceService WCFクラスは、Financeモジュールに実装されて操作を実行する別のインターフェイスに委任します。これにより、シンサービスファサードを維持し、実装をサービス実装に「プラグイン」して、たとえばモジュールがWCFを心配する必要がなくなります。 一方で、インターフェイスと実装を備えているという点で、各モジュールが自己完結していることが望ましい場合があります。サービスホストは、モジュールにあるサービスコントラクトインターフェイスを参照し、モジュールからの適切な実装も使用するようにIoCが構成されます。つまり、新しい.svcファイルとIoC構成情報を追加する以外に、サービスレイヤーを変更せずに新しいモジュールを追加できます。 標準のWCFからRESTfulサービスインターフェイスに切り替えるか、RIAサービスなどにアクセスした場合の影響について考えています。各モジュールにサービスコントラクトの実装が含まれている場合、サービステクノロジーまたはアプローチを変更すると、すべてのモジュールに変更を加える必要があります。しかし、ファサードが独自のモジュールである場合、変更するためにその部分を交換するだけです。モジュールは、共有アセンブリで定義されている可能性のある異なるコントラクト（インターフェイス）のセットを実装する必要がありますか？ 2.モジュール間でリソースを共有したり、モジュール間で依存関係を処理する最良の方法は何ですか？ たとえば、受信操作を考えます。商品を受け取ることは在庫機能であるため、最初は赤面でこれが在庫モジュールに入ることは理にかなっています。ただし、領収書を生成して支払いを承認する必要があるという点で、財務的な側面もあります。 一方では、操作を伝えるために何らかのタイプのドメインイベント/メッセージングを使用することを期待します。Inventoryモジュールは、Financialモジュールによって処理されるGoodsReceivedEventを発生させて、領収書を生成し、支払いプロセスを開始します。ただし、これは、金融モジュールが受け取った在庫品目について知る必要があることを意味します。IDで単純に参照できますが、名前や説明、単価など、領収書の追加情報が必要な場合はどうすればよいですか？各モジュールが、そのモジュールのニーズに合うように設計されたインベントリアイテムの独自のバージョンを持つことは理にかなっていますか？その場合、GoodsReceivedEventを処理するときに、Financialモジュールは在庫アイテムの独自のルックアップを実行する必要があります。 ... さまざまなERPシステムで多くの作業をしており、このタイプのモジュール方式で設計されていることを知っているため、この例を意図的に使用しました-方法がわかりません。また、上記では明示的に言及していませんが、ドメインドリブンデザインの原則に従ってソリューションを設計し、このタイプのモジュール性がその領域にぴったりと収まると考えています。 私の頭をこれに巻き付ける助けは大歓迎です。

11 architecture  domain-driven-design  wcf  soa  modules 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 4年前に閉鎖されました。 システムを作成する際に考慮しなければならないことがたくさんあります。たとえば、ユーザーがログインして相互作用し、コンテンツを作成および編集するWebベースのシステムを考えてみましょう。今、私はセキュリティ、バリデーション（私はそれが何を伴うのかを100％確信しているとさえ思わない）、「ユーザーがお互いの足を踏まないことを確認する」（これを言う？）、多くのエラーを防ぐことを考えなければならない予期せぬ状況でデータベースデータが問題にならないようにしていますか？どのように、どこで学ぶべきかわからないこれらすべてのことについて、この種のものに関する本はありますか？私が言ったように、コードを書くことと実際に正しいコードを書くことの間には大きな違いがあるように思えます。私の現在のプログラミング作業は、私が説明したものの多くを欠いているように感じ、後でそれが引き起こす問題を見ることができます。そして、データが存在し、人々がそれを使用しているため、問題を解決するのははるかに困難です。だから誰も私にこのタイプの学習のための本やリソース、またはプログラミングの適切なサブセット（？）を教えてもらえますか？ PS：自由にタグを修正してください。何を言っているのかわかりません。 編集：私が書いた例のいくつかは他のタイプのシステムにも当てはまると思います。私は主にウェブの仕事に携わっているので、他の良い例は知りません。

11 learning  design  architecture 

ルールエンジンの機能に興味があります。 ビジネス駆動型ロジックの起動と反復 開発者ではなく、これらのルールの実際の変更を「ビジネスユーザー」に実行させる 一般的なビジネスルールを理解する また、ルールエンジンの使用はアプリケーションの品質に影響しますか？ 1台のマシンのセットアップ、アーキテクチャ、数千台のマシンを使用する多層クラウドベースの分散アーキテクチャに展開する場合、ルールエンジンの使用は変わりますか？どう違いますか？

11 architecture  rules-engine 

Open-Closed Principle（OCP）は、オブジェクトは拡張のために開かれ、修正のために閉じられるべきであると述べています。私はそれを理解し、SRPと組み合わせて使用​​して、たった1つのことを行うクラスを作成すると信じています。そして、すべての動作コントロールをサブクラスで拡張またはオーバーライドできるメソッドに抽出できるようにする多くの小さなメソッドを作成しようとしています。したがって、依存関係の注入と構成、イベント、委任など、多くの拡張ポイントを持つクラスになります。 次の単純で拡張可能なクラスを考えてください。 class PaycheckCalculator { // ... protected decimal GetOvertimeFactor() { return 2.0M; } } たとえば、OvertimeFactor1.5に変更するとします。上記のクラスは拡張するように設計されているため、簡単にサブクラス化して別のを返すことができますOvertimeFactor。 しかし ... ...クラスは拡張用に設計され、OCPに準拠していますが、問題のメソッドをサブクラス化およびオーバーライドしてからIoCコンテナー内のオブジェクトを再配線するのではなく、問題のメソッドを変更します。 その結果、OCPが達成しようとしていることの一部に違反しました。上記の方法は少し簡単なので、怠けているように感じます。OCPを誤解していますか？私は本当に何か違うことをするべきですか？OCPのメリットをさまざまに活用していますか？ 更新：回答に基づいて、この人為的な例は、いくつかの異なる理由で貧弱な例のように見えます。この例の主な目的は、オーバーライドされると、内部コードまたはプライベートコードを変更せずにパブリックメソッドの動作を変更するメソッドを提供することにより、クラスが拡張されるように設計されたことを示すことでした。それでも、私は間違いなくOCPを誤解していました。

11 design  design-patterns  architecture  object-oriented 

最近、建築家は、トヨタ（Web Forms）だけが必要なときにロールスロイスソリューション（MVC）を提供していると当社を説明しました。 アーキテクチャの選択としてのWebフォームとMVCについてのあなたの考えを知りたいと思います。

11 asp.net  architecture  mvc 

DRY Principle（Do n't Repeat Yourself）は、「すべての知識は、システム内で単一の明確な権威ある表現を持たなければならない」と述べています。ほとんどの場合、これはコードを指しますが、多くの場合、ドキュメントにも拡張されます。 すべてのソフトウェアシステムには、選択したかどうかに関係なくアーキテクチャがあると言われています。つまり、構築するソフトウェアには構造があり、その「構築された」構造がソフトウェアのアーキテクチャです。 構築されたソフトウェアシステムにはアーキテクチャが付属しているため、そのシステムのアーキテクチャ記述を作成することはDRY原則に違反していますか？ 結局のところ、アーキテクチャを知る必要がある場合は、常にコードを見ることができます...

11 agile  documentation  architecture  dry 

シナリオ： スタック：Java、Spring、Hibernate。 モデル：クライアントサーバーアプリケーション。 パターン：Model-View-Controller（MVC）。 サービス層クラスには3つの動作があります。 一部のサービスには、メソッド内にビジネスルールがあり、永続性をアプリケーションに委任します。お気に入り： EntityManager.save（entity）; 一部のサービスは、単純にデータベース関数（パラメーターを渡す）を呼び出します。 CallableStatement cls = con.prepareCall（ "{call databaseFunction（args）}"）; 一部のサービスには、両方の動作を持つメソッドがあります。 私の質問： アプリケーションサービスに直接データベース機能を呼び出しても問題はありませんか？これは悪い習慣ではありませんか？このようなプロジェクトに適用できるアーキテクチャモデルは何でしょうか？ 同じサービスで動作が混在することに問題はありますか？トランザクションや一貫性など？ メンテナンスの場合、このカプセル化により、開発者はデータベースの機能も変更する必要があることがわかりにくくなりますか？これを回避するには？ このシナリオは世界中の他のアプリケーションで発生しますか、それとも単なるアーキテクチャ上のエラーですか？

11 design-patterns  architecture  mvc  code-quality 

私はモノリシックなアプローチに慣れているので、マイクロサービスアーキテクチャに頭を抱えようとしています。 非常に簡素化された Uber予約システムを構築しようとしているとします。：物事を単純化するために、我々は、我々は3つのサービスとクライアントのゲートウェイAPIを持っているとしましょうBooking、Drivers、Notificationと私たちは、次のワークフローを持っています： 新しい予約を作成する場合： 既存のユーザーがすでに予約しているかどうかを確認する 利用可能なドライバーのリストを取得する ドライバーに通知を送信して予約を受け取ります 運転手が予約をピックアップ すべてのメッセージングがkafkaのようなメッセージングバスではなくhttp呼び出しを介して行われるとしましょう。 したがって、この場合、Bookingサービスは既存の予約の確認を行うことができると思いました。しかし、利用可能なドライバーと通知のリストを誰が取得する必要がありますか？ゲートウェイレベルで実行することを考えていますが、ロジックは次の2つの場所に分割されています。 Gateway -利用可能なドライバーのリストを取得+通知を送信 Booking -既存の予約を確認する そして、ゲートウェイはそれを行うのに適切な場所ではないと確信していますが、Bookingサービスでそれを行っている場合、緊密に結合されているように感じますか？ さらに複雑にするために、予約システムを再利用したいが、独自のビジネスロジックを追加した別のプロジェクトがある場合はどうなるでしょうか。新しいプロジェクトゲートウェイが独自のビジネスロジックを既存のものから分離できるように、ゲートウェイレベルでそれを行うことを考えたのはそのためです。 それを行う別の方法は、各プロジェクトがコア予約サービスと通信する独自​​の予約サービスを持っていることですが、ここでの最善のアプローチは何なのかわかりません:-)

11 architecture  microservices  business-logic 

私はWebベースのSaaSソリューションを構築しようとしており、マルチテナンシーまたはマルチインスタンスを使用するかどうかわからないところに行きました。私が達成しようとしていることと、それぞれのアプローチの長所と短所（読んだことによると私の意見）について説明しようと思います。どちらか一方のアプローチで何かを見逃した場合に備えて、提案を含めてください。 私が構築しようとしているアプリケーションは、前述したように、企業がアカウントを作成できるSaaSソリューションであり、各アカウント/企業には独自のユーザー、顧客、製品、サービスなどがあります。各ユーザー; 会社の従業員は誰ですか。1つのアカウント/会社に関連するユーザーは、その会社の顧客、製品、およびサービスにのみアクセスできます。企業は無制限の数の顧客、製品、サービスを持つことができるため、各企業には独自のデータセンターが必要です。 そのため、共有データベース（ログインのためにすべてのユーザーの資格情報を保存する）と複数のデータベース共有スキーマ（アカウント/会社ごとのデータベース）を作成することにしました。基本的に、マルチテナント。 次に、誰かが代わりにマルチインスタンスを使用することを提案しました。そこでは、各会社が他の会社から完全に分離されたアプリケーションの独自のインスタンス（つまり、コード、ライブラリ、データベース、フレームワークなど）を持ちます。これは、各テナントのユーザーが会社のデータにのみアクセスできることを確認する必要がある追加のレイヤーを処理する必要がないため、より良いように聞こえます。私がこのアプローチを達成するためにDockerに依存していることを言及するのは良いことだと思います（私は以前にそれを使用したことがありません）が、機能が不足していると思います（詳細は後で説明します）将来必要になるでしょう（少なくとも私はしませんでした）少し検索しても見つかりません）。 ただし、どちらのアプローチにも長所と短所があるため、どちらのアプローチを選択するか決定できませんでした。ここにリストがありますが、両方の知識が不足しているので、私にはわかりません。私が知らないことや、Webで見つけられなかった問題の解決策がある可能性があります。[各アプローチには私が1つずつ比較した順序付けられたリスト] マルチテナンシー： 共有ホスト/ハードウェア、共有コード、およびマルチデータベース。 それはだ簡単にコードと修正のバグの機能（共有コード）を拡張します。 ハードウェアを拡張する（クラウドサービスを使用できる）か、コードに変更を加えずに個々のテナントのデータベースを別のシステムに移動するのは困難です。 最も重要なことは、前述したように、ユーザーが実際に自分の会社に属していて、他の会社の情報にアクセスしていないことを確認するために、システムに追加のレイヤーを追加する必要があります。 マルチインスタンス： 共有または非共有のホスト/ハードウェア、インスタンスごとのコード、インスタンスごとのデータベース。 それはだ難しく（あなたは1つのインスタンスまたはドッカーコンテナに機能/機能を追加し、他の人にそれを展開することができドッカーでそれを行う方法がある場合、私はわからない）機能や修正のバグを拡張します。 それはだ簡単に別のホスト/ハードウェアに全体のインスタンスを移動すること。 インスタンスとして、各インスタンスは独自のデータベースを持っているので、そのレイヤーを処理する必要はありません。 （各テナントのインスタンスを手動で作成するなどして）手動で何かを実行したい場合は、長所と短所のすべてが冗長であり、それがDockerソリューションを疑う理由です。質問の理由。解決策を参照して質問に答えていただければ幸いです。なぜこのアプローチが他のアプローチよりも優れていると思いますか。 それが役立つ場合（多分？）、バックエンド（すべてRESTful）のメインフレームワークとしてLaravelを使用しています。

11 architecture  software-as-a-service  laravel  multitenancy  docker 

私はマイクロサービスについて読みましたが、分離を実現するためだけにサービスごとに個別のDBを作成するのは私には非論理的です。Webサービスと単一のデータベースのみを使用して同じことを実現できます。なぜそれが必要なのですか？データベースを分離することは議論の余地があります。または私は明らかに間違っていますか？これについて教えてくれませんか？

10 architecture  database  web-services  microservices  services 

2つのクラスDogと、Cat両方がAnimalプロトコルに準拠している（Swiftプログラミング言語に関しては、Java / C＃のインターフェースになる）と考えてください。 犬と猫の混合リストを表示する画面があります。Interactor舞台裏のロジックを処理するクラスがあります。 ここで、ユーザーが猫を削除するときに確認アラートを表示します。ただし、犬はアラートなしですぐに削除する必要があります。条件付きのメソッドは次のようになります。 func tryToDeleteModel(model: Animal) { if let model = model as? Cat { tellSceneToShowConfirmationAlert() } else if let model = model as? Dog { deleteModel(model: model) } } このコードはどのようにリファクタリングできますか？それは明らかににおいがする

10 architecture  refactoring  software  architectural-patterns  polymorphism