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

私は、金融/保険業界の大企業（従業員3万人）で働いています。「IT」は主な焦点ではありませんが、正直に言って、これらは情報主導型の産業であり、技術的優位性のある企業はより早く前進しているようです。 私の会社には多くのソフトウェア開発チームがいます。言語やフレームワークはもちろん、バージョン管理機能を備えたマップ上にあります。何も使用しない（知っている）、PVCSを使用するもの、VSSを使用するもの、SVNを使用するものがあります。 gitを企業に持ち込みたい。具体的には、GitHub（プライベートリポジトリ）を持ち込みます。これについて話すのにふさわしい人は知っていますが、正直言って、このような抜本的な動きは、あいまいなセキュリティの懸念や競合他社がそれを使用していないという事実のために、大企業の環境で通常撃ち落とされます参照としてjQuery、Ruby on Rails、Facebookなどのみを引用してください）。 私の質問はこれです。大企業がPVCS / VSS / SVNからGitHub（プライベートリポジトリ）などのホストされたgitソリューションにゆっくりと慎重に切り替える必要がある理由の最も説得力のある理由は何ですか。もちろん、私の計画の一部には、必須ではない開発プロジェクトのPOCが含まれます。

12 version-control  git  github  enterprise-architecture 

クラウドコンピューティングは、サイトでITインフラストラクチャを維持する際の苦痛のいくつかを軽減するのに十分成熟していますか？もしそうなら、それを採用することの欠点のいくつかは何ですか？セキュリティとプライバシーは大きな懸念事項ですか？

12 cloud-computing  enterprise-architecture 

現在の状況 私たちは、マイクロサービスアーキテクチャでオンラインショッピングWebアプリケーションを実装しています（そして現在保守しています）。 要件の1つは、エクスペリエンスと最終的な注文をカスタマイズするために、顧客がカートに追加するものにルールを適用できる必要があることです。明らかに、ビジネスルールエンジンを導入する必要があり、このために特定の「マイクロサービス」を実装しました（まだそう呼べる場合）。 1年の間に、このルールエンジンはますます複雑になり、より多くのデータ（カートのコンテンツだけでなく、ユーザー情報、役割、既存のサービス、請求情報など）が必要になりました。それらのルールを計算します。 現時点では、shopping-cartマイクロサービスは他のマイクロサービスからこのデータをすべて収集しています。このデータの一部はで使用されますがshopping-cart、ほとんどの場合、主にルールエンジンのフィードに使用されます。 新しい要件 これで、同様の要件にルールエンジンを再利用する他のアプリケーション/マイクロサービスが必要になりました。したがって、現在の状況では、ルールエンジンを呼び出すことができるように、同じ種類のデータを送信し、同じマイクロサービスを呼び出し、（ほぼ）同じリソースを構築する必要があります。 そのまま続行すると、いくつかの問題に直面します。 誰もが（ルールエンジンを呼び出して）データのフェッチを再実装する必要があります（自分でデータを必要としない場合でも）。 ルールエンジンへの要求は複雑です。 この方向で続けると、多くの要求のためにこのデータをネットワーク全体に転送する必要があります（μsAがルールエンジンを呼び出すμsBを考えますが、Aはルールエンジンが必要とするデータの一部を既に持っています）。 shopping-cart すべてのデータ取得により巨大になりました。 おそらく多くのことを忘れてしまいます… これらのトラブルを回避するために何ができますか？ 理想的には、ルールエンジンの複雑さを増やさないようにします。また、ボトルネックにならないように確認する必要があります。たとえば、一部のデータはフェッチに時間がかかります（10秒以上）ためshopping-cart、ルールを呼び出す前にデータが存在する可能性が高くなるようにプリフェッチを実装しましたエンジン、および許容できるユーザーエクスペリエンスを維持します。 いくつかのアイデア ルールエンジンに必要なデータをフェッチさせます。これにより、さらに複雑さが増し、単一の責任原則に違反します（さらに…）。 ルールエンジンがデータを取得する前にプロキシμsを実装します。 ルールエンジンが必要なすべてのデータを一度にフェッチするために呼び出す「データフェッチャー」μsを実装します（複合照会）。

12 design  architecture  enterprise-architecture  microservices  business-rules 

2つのエンタープライズ統合パターンは、コマンドメッセージとイベントメッセージです。私は、他のシステムとの統合だけでなく、サービス間の内部通信にもメッセージングを使用するシステムに取り組んでいます。ことになって最終的に一貫性のあるシステム、およびサービスは、（カップル専用のサービスへの例外を除いて）お互いの無知ことになっています。そのため、リモートプロシージャコール（RPCまたはRPI）のように感じることは避けようとします。バスとメッセージ指向のミドルウェアシステムがあり、すべてのメッセージがブロードキャストされます。 私たちは、過去完了でフレーズとして、あるイベント、例えば、として私たちのメッセージに名前を付ける傾向がありますPurchaseOrderShipped。ただし、多くの場合、イベントは他のサービスがイベントについて知る必要がある場合にのみ追加され、最初は多くの場合1つのサービスのみが重要です。さらに、そのサービスは結果としてイベントを発行することがあり、そのイベントは最初のサービスでリッスンされます。したがって、相互作用を図にすると、イベントメッセージの図よりも上のリンクのコマンドメッセージの図（またはRPC図）のように見えますが、これは実際には実装されていませんダイレクトメッセージングですが、バスでブロードキャストします。それに加えて、コマンドとして名前が付けられたいくつかのメッセージが追加されたことを最近見たという事実、つまり、命令のフレーズ、例えばBillShippedPurchaseOrder。 奇妙なことに、メッセージの名前とその流れは、イベントとして命名されたかコマンドとして命名されたかによって変わりません。では、何かがコマンドメッセージかイベントかをどのように判断するのでしょうか？これはセマンティクスと命名の単なる違いですか、それともコマンドとイベントメッセージの実際の実装の違いはありますか？すべてのメッセージがブロードキャストされていることを考えると、それらのどれもが本当にコマンドメッセージではないということですか？

11 enterprise-architecture  messaging  event  command-message 

「エンタープライズ」という用語は、ソフトウェア開発者やプログラマーの周りに頻繁に投げ込まれ、大まかに使用されているようです。 en・ter・prise / ˈentərˌprīz / 名詞：プロジェクトまたは事業。通常は困難であるか、努力が必要です。イニシアチブと機知。 誰かがこの用語が実際に含むものを明確にしてください？「企業レベル」、「企業規模」？ものの「エンタープライズ版」もあります。正確にはどういう意味ですか？上記の定義から判断すると、ソフトウェアに対してより具体的に判断するのは明らかに意味がありません。エンタープライズという言葉を使用した場合の意味は何ですか？ 編集： これにスピンを追加するには-この用語は、Enterprise Framework Modelなどのフレーズにどのように適合しますか？データアクセスとデータコンテキストは、会社全体の説明と何の関係がありますか？

11 enterprise-architecture  enterprise-development  language-discussion 

誰もがWindows Workflow FoundationをBusinessRules / Validationエンジンに正常に使用したかどうか、またはこれに関するサンプルコードや記事を知っているかどうか疑問に思っていました。 以前に使用したことがある場合、それについてどう思いますか？他のBusinessRule / Validationシステムと比較してどうですか？ 私は次のようなルールを考えています if (A, B, and C) AllowAccess(); または if (Value between X and Y) return true;

11 enterprise-architecture  validation  business-rules  workflow-foundation 

免責事項 私は誰かのつま先を踏んだり、どちらかのコンセプトの愛好家を怒らせたりしていないことを願っています バックグラウンド 私は明確な答えを見つけることなく、サービス指向アーキテクチャとマイクロサービスの真の違いを探していました。 私は次のようなものを読みます： SOAの副作用 SOAはアンチパターン マイクロサービスはSOAの障害を修正するようになりました ESBは実際にはESBではなく、EAIです。 メッセージブローカーへの過度の依存 ベンダーはSOAの概念を悪用し、自社製品の販売を試みています SOAが制御不能に成長する しかし、それでもなお、サービス指向アーキテクチャー（概念として）とマイクロサービス（概念として）の間のアーキテクチャーの違いを明確に定義するものはありません 私が理解したところによると、彼らはどちらも持っています： 1つのことだけを行うサービスプロバイダー これらのサービスをコンシューマーに公開するService Gateway / ESB ESB / Service Gatewayを介してサービスにアクセスするサービスコンシューマー 質問 では、SOAをマイクロサービスに再ラベル付けする以外に何か違いはありますか？マイクロサービスがマクロになることを制限するために配置されたテクノロジーの制約ですか？ 注：箇条書きで意見を探すのではなく、難しい事実を探しています。 参考文献 ソフトウェア工学の質問 マーティン・ファウラーのサイト（彼はそれが大いに嫌いだと思う） 情報の世界 マイケル・フェザースのウェブサイト スタックオーバーフローの質問 更新 スタックオーバーフローの質問でも同様の議論が起こったようです。意見が分かれるかどうかにかかわらず、マイクロサービスは変装したサービス指向アーキテクチャーです。 SOの質問からの結論： MSはSOAの特殊なケースです MSは、サービスをホスティングするアプリケーションのより小さなサイズを推奨します MSはテクノロジーに依存します（オープンプロトコルオプションではなくHTTPの使用） MSはテクノロジーを利用して規律を強化します（サービスの自動展開） MSはESB（悪）を考慮しますが、IMHOがESBの一種である APIゲートウェイを使用します 次の条件に当てはまる場合、MSはSOAであると結論付けます。 MSはオーケストレーションの概念をサポートしていますか？ワークフローを管理する1つ以上のマスタープロセス MSにメッセージブローカーレイヤーはありますか？メッセージフォーマットをサービスプロデューサーのメッセージスペースからサービスコンシューマーに変換する一連のアダプター マイクロサービスはモノリシックエンタープライズアプリケーションからデータを読み取ることができますか？モノリシックアプリケーションのAPIにすることはできますか？それとも独立して動作できるスタンドアロンの自己完結型アプリケーションでなければなりませんか？ 最後の質問に対する答えが「いいえ」であることが判明した場合、マイクロサービスは、クレジットカード管理システムや照合システムなどの複雑なワークフローシステムを処理することができません。

10 microservices  enterprise-architecture  soa 

私はキャッシュメカニズムを使用していないので、次のシナリオで.netの世界で私のオプションは何なのかと思っていました。 基本的に、ユーザーがカテゴリー（フォルダーと考える）のIDを渡すRESTサービスがあり、このカテゴリーには多数のサブカテゴリーがあり、各サブカテゴリーには1000のメディアコンテナー（ファイル参照オブジェクトと思う）があり、 NASまたはSANサーバー上にある可能性のあるファイル（この場合、ファイルはビデオです）。これらのカテゴリ間の関係は、いくつかの権限ルールとサブカテゴリに関するメタデータとともにデータベースに保存されます。 したがって、UIの観点からは、遅延して読み込まれたツリーコントロールがあり、これはユーザーが各サブフォルダーをクリックすることによって駆動されます（Windowsエクスプローラーと考えてください）。ビデオファイルのURLにアクセスすると、ビデオを見ることができます。 システムが成長するにつれて、ユーザー数は1000に増加し、サブカテゴリとビデオは10000になる可能性があります。 問題は、各リクエストがデータベースにヒットする現在の動作方法を続行する必要があるか、それともデータのキャッシュについて考える必要があるかです。 IIS 6/7とAsp.netを使用しています。

10 design  architecture  asp.net  enterprise-architecture  iis 

私の会社はWebアプリケーションをゼロから書き直しています。これは、金融業界で複雑なドメインを持つ大規模なエンタープライズレベルのアプリケーションです。 永続化のためにORM（エンティティフレームワーク）を使用しています。 本質的に、アプリケーションの半分はユーザーから生データを収集して保存することに集中しており、実際のドメインロジックのほとんどを含むアプリケーションの残りの半分はその生データを使用して、元のデータとは大きく異なるドメイン画像を作成します生の入力、およびそれを計算エンジンに渡し、計算を実行し、結果を吐き出し、ユーザーに表示します。 レイヤーを使用したDDDアプローチでは、CRUD操作がドメインレイヤーを通過するように見えます。しかし、少なくとも私たちの場合、これは意味をなさないようです。 たとえば、ユーザーが編集画面に移動して投資口座を変更した場合、画面のフィールドはデータベースに保存されているフィールドそのものであり、後で計算に使用されるドメイン表現ではありません。では、編集画面でデータベース表現（生の入力）が必要なときに、なぜ投資口座のドメイン表現を読み込むのでしょうか。 ユーザーが投資口座画面で[完了]をクリックし、コントローラーに対してPOSTが実行されると、コントローラーには、保存する必要のある投資口座のほぼ正確なデータベース表現が表示されます。しかし、何らかの理由で、コントローラーのモデルをデータベースモデル（エンティティフレームワークモデル）に直接マッピングするのではなく、ドメイン表現をロードして変更を加えることになっていますか？ つまり、本質的には、データモデルをドメインモデルにマッピングします。これにより、永続化するためにデータモデルにマッピングし直すことができます。それはどういう意味ですか？

9 design-patterns  object-oriented-design  domain-driven-design  enterprise-architecture 

最新のプログラムで人気のある高レベルのアーキテクチャの選択は、RESTベースのマイクロサービスシステムです。これには、疎結合、再利用の容易さ、使用できるテクノロジーの制限の制限、高いスケーラビリティなどのいくつかの利点があります。 しかし、そのようなアーキテクチャーで私が予測する問題の1つは、アプリケーションの依存関係が何であるかについての可視性が低いことです。たとえば、1組のREST呼び出しを毎日使用するアプリケーションがあるとします。このアプリケーションは、REST呼び出しの2番目のセットも使用しますが、四半期に1回だけです。過去1週間のログをスキャンすると、1日のカロリーはすべて表示されますが、四半期ごとの呼び出しは表示されません。リファクタリングの時期になると、四半期ごとの呼び出しが中断するリスクが高くなります。 このリスクを軽減し、疎結合アーキテクチャの依存関係をより詳細に可視化するために使用できるパターンまたはツールは何ですか？

9 architecture  rest  enterprise-architecture  microservices  coupling 

ソフトウェアのアーキテクチャと設計の観点から、マイクロサービスはミドルウェアに対してどのように「積み上げ」られますか（意図されていません）私はJavaから来ています。APIとしてのまっすぐなRESTから離れ、少なくともJavaでさまざまなレイヤーと接続パラメーターを抽象化すると、非常に古い学校のアイデアにほぼ完全に戻ってきたようです。仮想化に戻りました... JVMがすでに仮想化されているかどうか。 不可知論的な方法で、RESTful APIをCORBAに抽象化することができ、その利点を主張します。または、よりJava中心の方法で、JMSまたはMDB。 かつて、EJBはJavaで大きな問題でしたが、それがクラスター効果の一部であると認識されていましたが、今、最初に戻りましたか？ または、マイクロサービスは、CORBA、またはさらに優れたMDBにはないものを提供しますか？マイクロサービスの説明（TLDR）Martin Fowlerを読んだとき、もしそうなら、それは悪い問題の良い解決策として私を驚かせます。むしろ、問題を押し広げるだけの複雑さのレベルをもたらすクローズドマインドアプローチ。サービスが本当にマイクロで数が多い場合、それぞれのサービスの実行と維持に1ドルのコストがかかります。 さらに、多くの中で1つのマイクロサービスがそのAPIを変更すると、そのサービスに依存するすべてが壊れます。それはしないように見えるそれは、疎結合思わアジャイルの反対を。それとも私はそれらの言葉を誤用していますか？ もちろん、これらの両極端の間には不確定な量の選択肢があります。 サメ対ゴリラ...行く！ （知識を深めるために、それは皮肉なことを意味し、私の意図ではありません。質問は額面通りに受け取られることを意味します。質問を改善できる場合は、そうするか、コメントしてください。修正します。 ） Dockerで実行されている多数のマイクロサービスがすべて1台のマシンで実行され、互いに対話していることを想像してください...狂気。保守や管理が難しく、変更を重ねると予期しないエラーが発生するため、何も変更することはほとんど不可能です。これらのサービスが異なるマシンに分散していることはどういうわけですか？そして、それらが分散されている場合、確かに、非常に古くからあるいくつかの手法が、少なくともある程度、分散コンピューティングを解決しています。 なぜ水平スケーリングが普及しているか、少なくとも望ましいのですか？

9 java  enterprise-architecture  distributed-computing  client-server  middleware 

私の会社は、すべてのティア1（つまり、トップエンドの本番）アプリケーションとサイトを1つの包括的なコードベースに統合することを検討しています。 理論は、それらの権限、デザイン、および全体的な機能を均質化し、集中管理できるというものです。 各アプリケーションの基盤となるデータ構造は非常に異なり、ビジネスルールは複雑で、各アプリケーションに固有であり、既存のアプリケーションの全体的なコードベースは非常にバラバラで無視されているため、このアプローチに終わりはありません。 編集： 現在の環境は、最初に書かれて以来ほとんど愛されていない3つのASP.Net 1.1サイト（主に社内の経験豊富な開発者がいないため）と、以前はASP.Net 1.1サイトでもあった1つのMVC2アプリケーションで構成されています。昨年アップグレードされました。C＃のみで書き込みます。 同社はかなり小規模で、約50人のスタッフがいます。3人は実際の開発者です。管理（IT管理であっても）には、ITプロジェクトのプロジェクト管理（したがって、専門用語やビジネスへの影響に関するある程度の知識）以外のITの背景や経験はありません。 アプリケーションは主に、同社が販売する製品をサポートするオンラインサービスです。同社はソフトウェアを直接販売していません。 したがって、この状況全体をかなり具体的で答えられる質問で言い表す：現在の条件（つまり、古いコードベース、複雑なビジネスシステムおよびルール）を前提として、すべてのシステムを1つの包括的なソリューションにまとめようとすることに対する、または反対する説得力のある理由は何ですか？ ）？

9 asp.net  enterprise-architecture 

私たちのチームは当初、JavaScriptの専門知識が最小限のサーバー側開発者で構成されていました。ASP.NETでは、コードビハインドで、または最近ではMVCのコントローラーを介して多くのUIロジックを記述していました。 少し前に、2人の高レベルのクライアント側開発者がチームに加わりました。HTMl / CSS / Javascriptで、サーバー側のコードとサーバー側のWebコントロールを使用してこれまで実行できたことのほとんどすべてを実行できます。 コントロールの表示/非表示 検証を行う AJAX更新の制御 ：私はそれを考え始めので、多分ちょっとアマゾンフルフィルメントAPIのように、私たちのビジネスロジックの周りにハイレベルのAPIを作成する方が効率的でしょうhttp://docs.amazonwebservices.com/fws/latest/APIReference/、そのクライアントので、サイド開発者はUIを完全に引き継ぎ、サーバーサイド開発者はビジネスロジックのみに集中します。 したがって、注文システムでは、次のような高レベルのAPIを使用します。 OrderService.asmx CreateOrderResponse CreateOrder(CreateOrderRequest) AddOrderItem AddPayment - SubmitPayment - GetOrderByID FindOrdersByCriteria ... APIへのJSON / RESTアクセスがあるため、クライアント側のUIから簡単に利用できます。このAPIを使用して、内部UI開発とサードパーティが独自のアプリケーションを作成することもできます。 Javascriptの進歩と優れたクライアント側開発者の可用性により、コードビハインド/コントローラーを取り除き、クライアント側開発者が消費できる高レベルAPI（ala Amazon）の開発に集中するのは今が良い時期ですか？

9 javascript  architecture  asp.net  team  enterprise-architecture 

したがって、「Vaughn Vernonによるドメイン駆動設計の実装」を読んだ後、コアドメインの概念と思われるものを個別のモジュールに分離することにより、再利用性を高めるためにコードをリファクタリングすることにしました。 各モジュールには、ドメイン、インフラストラクチャ、アプリケーション/プレゼンテーションレイヤーを含む独自のアーキテクチャレイヤーのセットが含まれています（ヴォーンの推奨に従って、アプリケーションレイヤーの責任をルート、MVCコントローラー+テンプレートに存在するテンプレートからさらに分離することにしましたプレゼンテーション層）。 これらの各レイヤーを独自のパッケージ内に配置することにしました。各パッケージは、その下のレイヤーを依存関係として参照しています。つまり、プレゼンテーション層はアプリケーション層に依存し、アプリケーションはインフラストラクチャに依存します。リポジトリはドメインの一部であるため、各リポジトリインターフェースはドメイン層/パッケージ内に存在し、実装はインフラストラクチャ層/パッケージ（Doctrine 、など）。 この方法でコードを再構築することで、アプリケーションレイヤーをスワップアウトし、複数のWebアプリケーション間でドメインを再利用できることを願っています。 最終的にコードは再び形を整え始めているように見えますが、それでも私を混乱させるのは、アプリケーション、インフラストラクチャ、ドメインサービスのこの違いです。 ドメインサービスの一般的な例の1つは、パスワードのハッシュに使用するものです。ユーザーエンティティは、ユーザーの資格情報を格納するために使用される可能性のあるさまざまなハッシュアルゴリズムに関与する必要がないため、これはSRPの観点からは理にかなっています。 そのことを念頭に置いて、私はこの新しいドメインサービスを私のリポジトリと同じように扱いました。ドメインでインターフェースを定義し、実装をインフラストラクチャ層に任せることにより。しかし、私は今、アプリケーションサービスで何をすべきかについて考えています。 現在のところ、各エンティティには独自のアプリケーションサービスがあります。つまり、ユーザーエンティティにはアプリケーション層内にUserServiceがあります。この場合のUserServiceは、プリミティブデータ型の解析と一般的なユースケース「UserService :: CreateUser（string name、string email、etc）：User」の処理を担当します。 私が気になるのは、アプリケーション層を交換することにした場合、複数のアプリケーションにわたってこのロジックを再実装する必要があるという事実です。だから私はこれが私の次のいくつかの質問につながると思います： ドメインサービスは、インフラストラクチャレイヤーとモデル間の抽象化レイヤーを提供するために存在する単なるインターフェイスですか？例：リポジトリ+ HashingServicesなど 私はこのようなアプリケーションサービスを持っていると述べました： Access / Application / Services / UserService :: CreateUser（string name、string email、etc）：User メソッドシグネチャは、プリミティブデータ型の引数を受け入れ、新しいユーザーエンティティ（DTOではない！）を返します。 これは、ドメインレイヤー内で定義されたいくつかのインターフェイスの実装としてインフラストラクチャレイヤーに属しますか、それともプリミティブデータ型の引数などにより、実際にはアプリケーションレイヤーがより適切ですか？ 例： Access/Domain/Services/UserServiceInterface そして Access/Infrastructure/Services/UserService implements UserServiceInterface 個別のモジュールが一方向の関係をどのように処理するか。モジュールAは、モジュールBのアプリケーションレイヤー（現在行っているように）またはインフラストラクチャの実装（個別のインターフェイスを介して）を参照する必要がありますか？ アプリケーション層サービスには別のインターフェースが必要ですか？答えが「はい」の場合、それらはどこに配置する必要がありますか？

8 design-patterns  php  architecture  domain-driven-design  enterprise-architecture 

私はSaaSソリューションの構築を検討している企業のアーキテクトです。当社の製品は、さまざまなデプロイ可能なコンテナ、Webサービス、Web UIなどに分散されています。 私は、アプリケーションの設定を管理するためのオープンソースまたはサードパーティのソフトウェアソリューションを探しています。これらは、Word、Eclipse、またはVisual Studioにある設定と似ています。設定は、製品のさまざまな動作と機能を制御します。（おそらく、どのデータベースに接続するかなどの設定ではなく、デフォルトでページに行番号を表示するかどうかを指定します。）理想的には、さまざまなディメンションの値を（テナントごと、ユーザーごと、アプリケーション環境ごとに）格納できるようにするのが理想的です。 私たちは非常に多くの異なるデプロイ可能ファイルを持っているので、各デプロイ可能部品が個別の設定を取得できるWebサービスを提供できる集中型ソリューションを探しています。 この種の機能を提供する集中型サービスを知っている人や、私たち自身のサービスをロールする代わりの方法を探す手助けをしてくれる人はいますか？

8 enterprise-architecture  software-as-a-service