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

私はエンタープライズアプリケーションを構築する会社で働いており、開発（またはdev）、ステージング（またはステージ）、本番（またはprod）の3つの環境を維持しています。 devの意味は直感的です。アプリケーションの開発中に使用される環境です。 ステージング環境と運用環境の違いは何ですか？

80 enterprise-architecture  java-ee  enterprise-development 

私は、1000以上のテーブル、さらに数百のビュー、数千のストアドプロシージャを備えたSQL Serverデータベースを使用しています。新しいプロジェクトにEntity Frameworkの使用を開始したいと考えており、そのための戦略に取り組んでいます。ハングアップしているのは、テーブルを異なるモデルに分割する最良の方法です（最初にコードを作成する場合は、EDMXまたはDbContext）。私はすぐにいくつかの戦略を考えることができます： スキーマによる分割 テーブルはおそらく12個のスキーマに分割されています。スキーマごとに1つのモデルを作成できます。ただし、dboは500を超えるテーブル/ビューで非常に大きくなるため、これは完全ではありません。もう1つの問題は、特定の作業単位が複数のモデルにまたがるトランザクションを実行しなければならないことです。これにより、EFがこれをかなり簡単にすると仮定します。 意図 で分割するスキーマを気にする代わりに、モデルを意図で分割します。そのため、取得する粒度に応じて、アプリケーション、プロジェクト、モジュール、または画面ごとに異なるモデルを用意します。これに伴う問題は、UserやAuditHistoryなど、すべての場合に必ず使用する必要がある特定のテーブルがあることです。それらをすべてのモデルに追加しますか（DRYに違反すると思います）、それともすべてのプロジェクトで使用される別のモデルにありますか？ まったく分割しないでください-1つの巨大なモデル これは開発の観点からは明らかにシンプルですが、私の研究と直感から、設計時、コンパイル時、そしておそらく実行時の両方でひどく実行できるようです。 このような大規模なデータベースに対してEFを使用するためのベストプラクティスは何ですか？具体的には、この大量のDBオブジェクトに対してモデルを設計する際にどのような戦略を使用しますか 私が上で持っているものよりもうまく機能すると思っていないオプションはありますか？ また、これはNHibernateなどの他のORMの問題ですか？もしそうなら、彼らはEFよりも優れたソリューションを考え出しましたか？

50 entity-framework  orm  enterprise-architecture 

「通常の」ソフトウェアとエンタープライズソフトウェアの違いがわかりません。これらを読んだ後でも... ウィキペディアの「エンタープライズソフトウェア」 Techcrunchの「エンタープライズソフトウェアは再びセクシー」 コーディングホラーに関する「The Great Enterprise Software Swindle」 本当の違いに頭を悩ませることはできません。2つの間に何か違いはありますか？なぜエンタープライズソフトウェアが悪いと言われるのですか？

46 terminology  enterprise-architecture 

私は多くのRobert C. Martinのコンテンツを読んだり見たりしています。私は、ソリッドステートドライブのためにSQLが不要であると言ってきました。これをバックアップするために他のソースを検索すると、ハードドライブとソリッドステートドライブのSQLパフォーマンスの違いを説明するランダムな記事がたくさんあります（これは関連していますが、研究しようとしているものではありません）。 最終的に、私は彼が何を得ようとしているのか理解できません。彼はSQLをNo-SQLテクノロジーに置き換えると言っていますか？彼はファイルシステムのファイルにデータを保存すると言っていますか？それとも、SQLi攻撃のために、人々にSQL /リレーショナルデータベースの使用をやめさせたいのでしょうか？彼がやろうとしているポイントを逃しているのではないかと心配しています。 あなたが彼の心から直接読むことができるように、ここにいくつかのリンクを提供します： ボビーテーブル クリーン建築レクチャー まず、SQLをシステムから完全に削除する必要があると述べています。 ソリューション。唯一の解決策。システムからSQLを完全に削除することです。SQLエンジンがない場合、SQLi攻撃はありません。 また、彼はSQLをAPIに置き換えることについて語っていますが、その前の引用と彼が記事の前半で述べていることから、SQLをAPIの背後に置くことを意味するとは思いません。 フレームワークは問題を処理しません; ... サイドノート：SQLと言って、Robertはほとんどのリレーショナルデータベースを意味すると確信しています。すべてではないかもしれませんが、ほとんどです。いずれにせよ、ほとんどの人はとにかくSQLを使用しています。そう... データの永続化にSQLが使用されていない場合、何を使用することになりますか？ それに答える前に、私も注意する必要があります。ロバートは、ソリッドステートドライブがデータの永続化に使用するツールを変更する必要があることを強調しています。SørenD.Ptæusの答えはこれを指摘しています。 また、「データ整合性」グループに対応する必要があります。さらなる調査の結果、ロバートは、datomicなどのトランザクションデータベースを使用する必要があると述べています。その後、CRUDはCR（作成および読み取り）に変わり、SQLトランザクションは完全になくなります。データの整合性はもちろん重要です。 このすべてを網羅する質問は見つかりません。私はロバートのガイドラインに一致する代替案を探していると思います。Datomicは1つですが、それですか？これらのガイドラインに適合する他のオプションは何ですか？また、ソリッドステートドライブで実際に機能しますか？

45 architecture  enterprise-architecture  architectural-patterns  plugin-architecture 

私は、多くの問題に苦しんでいる非常に貧弱に設計されたソフトウェアプロジェクトへの変更を提案しています。高レベルでは、プロジェクトはフロントエンドでAngularを利用し、さまざまなREST APIを使用します。それはすべて素晴らしいことです（私たちの技術やツールを変更する必要はありません）。問題は、コードベースがUIでサーバー側のAPIよりも不均衡に大きいことです。ビジネスロジックの多くはUIに存在し、REST APIはUIレイヤーへの単純なCRUDデータベースインターフェイスです。 たとえば、顧客へのPOSTは顧客レコードを作成し、PUTはその顧客を変更します。それ以上でもそれ以下でもありません。ただし、ビジネスロジックはそれよりも要求が厳しくなります。顧客を作成する一般的なプロセスは、1つのデータベースレコードを挿入するだけではありません。他の必要なテーブルにデータをプロビジョニングし、特定の検証と計算などを実行します。この動作のすべてをカプセル化する単一のPOST / PUT呼び出しを行い、消費クライアントの負荷を軽減します。 したがって、私の視点では、この包括的なオーケストレーションはUIではなくサーバー（フルコントロール、ログなど）上に存在する必要がありますが、1つの反論は、このアプローチはRESTfulではなくなるということです。したがって、既存の技術スタックを継続することを推奨するが、コードが属する場所で基本的なシフトを実装することが推奨される場合、このアプローチをどのように説明するのが最適かはわかりません。

37 rest  api-design  enterprise-architecture 

現在のところ、この質問はQ＆A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 8年前に閉鎖されました。 「エンタープライズ」環境では、プロプライエタリなソフトウェアに対する強い偏見を観察しました。Javaを使用する大企業でも、MySQLやPostgreSQLを見つけることはまれであり、WebSphereやWebLogicはJBossやTomcatよりも強く推奨されます。 これは非常に理解しやすいです。多くの開発者はWebSphereやOracle DBよりもTomcatやPostgresを好みますが、これらの問題で最終決定を下すのは開発者ではありません。本番環境でどのDBとアプリケーションサーバーを使用するかを決定する人は誰でも、本当に、本当に、悪いことを引き起こしたフリーソフトウェアを選択したために解雇された場合と比較して、ライセンス料が非常に少ないように見えます。 PostgresがOracleと同じくらい良いかどうかの質問はしていません。それはポイントではありません。Oracleは、機能とベンチマークを慎重に検討した結果、Postgresよりも選択されません。特定の場所ではフリーソフトウェアが信頼されていないため、Postgresは会話に参加しません。 この信頼の欠如が特定の出来事に対応して生じたのではないかと思っています。だから私の質問はこれです：オープンソースソフトウェアの欠陥の結果であることが示されたビジネス災害（障害、収益の著しい損失、企業データの著しい損失など）の文書化された事例はありますか？ 明確化： OSSを完全に採用している企業レベルの企業での経験がある場合は、問題を先入観せず、特定の状況のニーズに基づいて選択する必要があります。あなたの経験は、他の企業が非常に異なる態度を持っているという事実を変えることはなく、これらの企業が少数派であっても私の質問は有効です。

21 open-source  business  enterprise-architecture  failure  proprietary 

私は、WCFベースのSOAの一部をサービスバスモデル（おそらくnServiceBus）に移行し、いくつかの基本的なpub-subを使用してCommand-Query Separationを達成するプロジェクトを検討しています。 SOAやサービスバスモデルは初めてではありませんが、最近まで「分離」という概念は、すぐに使えるデータベースミラーリングとレプリケーションに限定されていたことを認めています。それでも、最終的に一貫性のあるシステムのすべての利点を提供する一方で、多くの明らかな欠点（特に、適切なトランザクションサポートの欠如）を回避するように見えるため、私はこのアイデアに魅了されます。 基本的にESBアーキテクチャ（少なくともMicrosoftの世界では）の第一人者であるUdi Dahanの主題について多くのことを読みましたが、彼が言うことの1つは本当に私を困惑させます。 より多くのフィールドを持つより大きなエンティティを取得すると、それらの同じエンティティを操作するアクターも多くなり、特定の時点で何かが何らかの属性に触れる可能性が高くなり、同時実行の競合の数が増加します。 [...] CQRSの中核となる要素は、ユーザーインターフェースの設計を再考して、ユーザーの意図を捉えることができるようにすることです。これにより、ユーザーを優先させることは、ユーザーが移動したことや得たことを示すこととは異なる作業単位であるようになります既婚。上で見たように、データの変更にExcelのようなUIを使用しても意図はキャプチャされません。 - ウディダハン、CQRSを明確化 引用で説明されている観点から、その論理について議論することは困難です。しかし、SOAに関しては穀物に反するようです。SOA（および実際のサービス全般）は、粗雑なメッセージを処理して、ネットワークチャターを最小限に抑えるようになっています -他の多くの利点があります。 優れたメッセージキューイングを備え、RPCの手荷物のない高度に分散されたシステムを使用している場合、ネットワークチャターは問題になりませんが、問題を完全に却下することは賢明ではないようです。Udiは、すべての属性の変更（つまり、フィールドの更新）を独自のコマンドにする必要があるとほとんど言っているようです。これは、従来のウェブサービス。 高度にパラメーター化された適切なクエリ、テーブル値パラメーター、またはステージングテーブルへの一括挿入を行うと、SQL Serverの1つのバッチ更新に数秒の時間がかかる場合があります。これらの更新を一度に1つずつ処理するのは遅く、遅く、遅く、OLTPデータベースハードウェアはスケールアップ/スケールアウトに最もコストがかかります。 これらの競合する懸念を調整する方法はありますか？私はそれについて間違った方法で考えていますか？この問題には、CQS / ESBの世界でよく知られた解決策がありますか？ そうでない場合、コマンドの粒度の「適切なレベル」をどのように決定するのでしょうか。出発点として使用できる「データベース」のような3NFのような「標準」があり、慎重なプロファイリングが潜在的に重要なパフォーマンスの利点を示唆する場合にのみ逸脱しますか？ または、これはおそらく、さまざまな専門家によっていくつかの強い意見が表明されているにもかかわらず、実際には単なる意見の問題であるものの1つですか？

17 architecture  enterprise-architecture  service-bus 

React（with Redux）とAngular 2を選択するための長い3か月にわたる議論と研究の末、私の会社のフロントエンドチームは、Angular 2を採用することを決定しました（私たちの問題により適しています）。 現在、多くの異なるフロントエンドテクノロジーで構成されているエンタープライズアプリビジネスに取り組んでいます（バックエンド全体をRESTfulにしています）。すべてを置き換えて、将来のトレーニングと品質管理を容易にする単一のテクノロジーが必要でした。 私たちの製品の性質を考えると、それは広大であり、その中には異なるドメインであり、スタンドアロンアプリとして作成できるモジュールがありますが、製品自体は単一のURLに存在します。 例; 私の製品をSuperAppと呼びましょう。 UIとして、SuperAppには標準のログインシステムと、子モジュール/サブ製品へのナビゲーションがあり、ワークフローは次のように表示されます。 SuperApp ユーザーを認証する パスワードを忘れたウィザード 認証なしでアクセスできる公開ページ 認証されたユーザー ナビゲーションシステム ホーム サブ製品1 サブ製品2 サブ製品3 プロフィール ... ... グループ ... ... 上記表現にそのノート、Sub-product1そしてSub-product2全く異なるビジネスドメインを有する、2つの全く異なる領域です。 私が今考えることができるのは、自分自身に関連するコンポーネントとビューのみを持つ単一のAngular 2プロジェクトとしてSuperAppを作成でき、SuperAppは複数の子アプリのロードも担当しているということです。Sub-product1、Sub-product2（自分の有する再び、異なる角度の2つのプロジェクトpackage.json、webpack設定、等）をダムコンポーネントを介して、トップレベルのルーティングを提供するシェルと、これらの子アプリを保持するためのプレースホルダとして機能します。 、いったんSub-product1シェル内にロードされ、それがSuperAppがで上陸したことを現在のルートに、独自のルートを追加します。 分離が必要な理由は、これらのさまざまなアプリ（現在はExtJSを使用して構築されている）が専用のチーム（私たちは500人以上の開発者を抱えている会社です）を持っているためです。グランド親アプリに依存せずに好みに依存します。 しかし、公式のAngularドキュメントやWebでは、ネストされたAngularアプリを持つことができるかどうかはまったくわかりません（子アプリの依存関係が完全に分離されてロードされている間にフレームワークコードが共有される方法で）またはそのような問題を解決するための代替アプローチがあるかどうか。 関連する記事へのガイダンスやリンクも歓迎します。

17 architecture  web-applications  enterprise-architecture  angular2  modularization 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 現在、一般的な顧客情報（ユーザーID、パスワード、姓、名、電子メール、住所、telfnrなど）のデータベースを作成する新しいプロジェクトの可能性を評価しています。この時点で、要件は大まかにのみ定義されています。 顧客DBは、何百万ものレコードに含まれていると予想されます。DBサイジングのためのいくつかの裏側の数値を計算し、潜在的なDBオプションとアーキテクチャを評価するために、これらの種類のレコードの事実上の標準を探しています。特に、すべてのフィールド（名、姓、住所など）の標準サイズ、または単純な顧客レコードの一般的な平均は素晴らしい情報です。 非常に多くのeコマースWebサイトがあるため、再利用でき、車輪の再発明を避けることができる、ある種の典型的な構成が必要です。 何か案は？ ----編集---- 答えは、標準の顧客レコードを採用するのではなく、独自のレコードを設計することに向かっているようです。この質問の焦点は、顧客オブジェクトのフィールドサイズの参照を見つけることであり、それを自分で理解することを避けることであることを強調したいと思います（元のテキストの部分を強調しました- 今は太字にしています）。

17 database  database-design  enterprise-architecture 

ポータルスペースでの幻滅 エンタープライズポータルの経験、特にWebSphere Portal Server（WPS）の領域に幻滅するようになった、大規模なエンタープライズクライアントの多くが気がかりです。何百万もの投資が行われていますが、集約および統合された共同作業ツールを使用したパーソナライズされたコンテンツの実現は決して実現していません。WPS 7.xへの移行は、大規模なリッピングと置き換えの動きであり、クライアントは完全に別の場所に移動すべきかどうか疑問に思っています。 ポータルソフトウェア：恐ろしいオプションですが、代替手段は何ですか ポータルには多くの嫌悪感があり、ポータルソリューションは実際には過剰すぎる場合がありますが、大規模な多国籍企業について話している場合、ポータルサーバーなしでグローバルソリューションを構築することをどのように推奨しますか？ ポータルは、TomcatやJBoss ASほど楽しいとは限りませんが、複数のアプリケーションの統合、コンテンツの管理、個々のwarファイルとしてデプロイされる個々のアプリケーションの更新、ポートレットレベルまでのセキュリティ管理、特定のユーザーへのパーソナライゼーションの量、および大規模企業が社内および社外のWebサイトの一部として持っている数千のページを管理するという圧倒的なタスクを支援するために、より良い技術がありますか？ コミュニティの洞察とフィードバックを集める 私はできるだけ多くの洞察を獲得しようとしています。この問題について、TSSに関する小さな記事を書きました。 ポータルには、他にどのような選択肢がありますか？ また、CodeRanchでスレッドを復活させて、そのハンサムな乗組員から洞察を得られるかどうかを確認しています。 ポータルソフトウェアの戦略に代わるものを求める更新されたスレッド。2012年頃 twitterati（@potemcam）からの洞察も探しています。 コミュニティからの鋭い洞察を本当に集めようとする試みであるので、クロスポストではありません。確かな反応と経験を得ることができたら、TSSのアドバイス記事にまとめたいと思います。 Javaスペースでのエンタープライズポータルの正しい代替手段は何ですか？ ちなみに、他のサイトからもこの質問にクロスリンクして、同じ質問をしている人が行き来して、このトピックに関してコミュニティが何を言っているかを確認できるようにします。

17 java  enterprise-architecture 

職場では、2年近く開発中の大規模な内部アプリケーションがあります。私は最近プロジェクトに参加しましたが、アーキテクチャの一部には少し困惑しているので、建築家に同じ質問をする前にここの誰かがアドバイスを提供できることを願っています）。 以下が少し長い場合は申し訳ありませんが、質問する前にシステムが何であるかをよく描きたいと思います:) システムのセットアップ方法は、1つのメインWebアプリケーション（asp.net、AngularJS）があり、ほとんどの場合、他のさまざまなサービスからのデータを集約するだけです。したがって、基本的には、AngularJSアプリケーションのホストです。文字通り、クライアント側をブートストラップする1つのMVCコントローラーがあり、他のすべてのコントローラーはWebAPIコントローラーです。 クライアント側からの呼び出しは、これらのコントローラーによって処理されます。これらのコントローラーは、Webアプリケーションをホストするだけのボックスに常に展開されます。現在、このようなボックスが4つあります。 ただし、呼び出しは最終的にさらに別のWebAPIアプリケーションのセットにルーティングされます（通常、これらはセキュリティ、顧客データ、製品データなどのビジネスエリアごとです）。これらのWebAPIはすべて、専用のボックスにも一緒にデプロイされます。また、これらのボックスが4つあります。 1つの例外を除き、これらのWebAPIは組織の他の部分では使用されません。 最後に、これらのWebAPIは「バックエンド」サービスをさらに別のセットで呼び出します。これは通常、さまざまなERPシステムおよびデータストア（制御不能）の上に置かれたレガシーasmxまたはwcfサービスです。 アプリケーションのビジネスロジックのほとんどは、これらのWebApiにあります。たとえば、レガシーデータの変換、集約、ビジネスルールの実行など、通常のタイプのものです。 私が混乱しているのは、WebApplicationと、それを提供するWebAPIをこのように分離することで得られる利点の可能性です。他の誰もそれらを使用していないため、スケーラビリティの利点はありません（つまり、APIサーバーの負荷の増加はWebサーバーの負荷の増加を意味するため、別の4つのAPIボックスを追加しても負荷はありません）したがって、WebサーバーとApiサーバーの比率は1：1でなければなりません） また、ブラウザ=> HTTP => WebApp => HTTP => WebAPI => HTTP =>バックエンドサービスを追加のHTTP呼び出しを行う必要があるという利点もまったくありません。（WebAppとWebAPI間のHTTP呼び出しが私の問題です） そのため、現在は、現在のWebAPIを個別のソリューションから、WebApplicationソリューション内の個別のプロジェクトに移動し、間に単純なプロジェクト参照と単一の展開モデルを配置することを検討しています。したがって、最終的にはクラスライブラリになります。 展開に関しては、これは4 + 4ではなく8つの「フルスタック」Webボックスがあることを意味します。 新しいアプローチのメリットは次のとおりです。 WebアプリケーションとWebAPIサーバー間のシリアル化/逆シリアル化のサイクルが1つ少ないため、パフォーマンスが向上します。 WebアプリケーションサーバーとWebApiサーバーのそれぞれの発信境界と着信境界のDTOとマッパーに関して削除できる（つまり、メンテナンス/テストする必要がない）大量のコード。 意味のある自動化された統合テストを作成する能力が向上しました。バックエンドサービスを単純​​にモックし、中間層のHTTPジャンプの混乱を回避できるからです。 だから質問は：私は間違っていますか？WebApplicationボックスとWebAPIボックスを分離したという基本的な「魔法」を見逃していませんか？ 私はいくつかのN-Tierアーキテクチャの資料を調査しましたが、状況に具体的な利益をもたらすことができるものを見つけることができないようです（スケーラビリティは私が知る限り問題ではなく、これは内部アプリなのでWebAPIアプリケーションに関するセキュリティは問題になりません。） また、システムを提案されたセットアップに再編成した場合、メリットの点で何が失われますか？

16 architecture  asp.net  enterprise-architecture  n-tier 

私は、数十のデータベーステーブル（集計、エンティティ/値オブジェクト）を使用する比較的複雑なアプリケーションで作業し、DDDを適用しています。この時点では、基本的にDDD-Liteのように見えます。つまり、アプリケーション/ドメインサービス、ドメインモデル（エンティティ、値オブジェクト）、およびリポジトリがあります。 私はDDDの実装という本を取り上げましたが、彼が最初に言及しているのは、DDDを開始するときによくある最初のミスとして、DDD-Liteおよびバウンドコンテキストとドメインイベントが欠落していることです。 現在、集計リレーションシップによってドメインモデルを整理し、ネームスペースを使用してそれを実証しようとしました。 ドメインモデルプロジェクトを個別のバウンドコンテキストに（まだ）分離することに関連する利点/欠点が見当たりません。おそらくそれは後で明らかになるかもしれませんが、バウンドコンテキスト（およびサブドメインなどが結び付けられている場合は、サブドメインなど）に関する実際のフィードバックをお願いします。

16 architecture  domain-driven-design  enterprise-architecture 

URLのREST APIのバージョンを指定することは非常に一般的です。具体的には、パスの先頭、つまり次のようなものです。 POST /api/v1/accounts GET /api/v1/accounts/details ただし、バージョンが各APIに関連付けられているデザインは見ていません。つまり、各APIのバージョンを個別に管理します。すなわち： POST /api/accounts/v2 GET /api/accounts/details/v3 このアプローチを使用すると、破壊的な変更が必要なときに特定のAPIのAPIバージョンをインクリメントします。API全体のバージョンをインクリメントする必要はありません。 一般的なスタイルの代わりにこのスタイルを使用することの欠点は何ですか？

15 rest  api-design  versioning  enterprise-architecture  engineering 

Windows 8向けのコンシューマアプリケーション開発の期待を把握していると思います。WinRTの上に新しいMetroベースのUIを作成し、Marketplaceを介して顧客に展開すると、誰もが勝ちます。簡単そうに思えます。残念ながら、私はそのビジネスにはいません。 私は、大企業向けの内部の基幹業務アプリケーションに取り組んでいます。現在、WebまたはClickOnceを介してユーザーに簡単に展開できるリッチUIを作成するために、WPFやSilverlightなどの.NETテクノロジーを使用しています。アプリケーションは、頭痛の種なしでWinXPとWin7をサポートでき、開発者は非常に強固なUIテクノロジーであるXAMLを使用できます。 WPFとSilverlightはこの時点で疑わしい未来を持っているように思われるので、それらに投資し続けることは少し心配です。しかし、Metro UIはエンタープライズアプリケーションに適切ではないように思われ、WinRT APIはエンタープライズアプリケーションが行う必要のある「典型的な」ことに関してかなり制限されています。 現在WinXPおよびWin7にデプロイされているXAMLベースのアプリケーションをどのように設計し、Win8でサポートおよび進化できるようにする必要がありますか？ この質問の目的のために、ASP.NETの上にあるHTML5によって提供される機能は、私が作成しようとしているアプリケーションには不十分であると仮定します。一部のアプリケーションでHTML5を使用できることは理解していますが、それでは不十分な場合に何をすべきかを考えています。 編集＃1： これは、@ Emmad Kareemのコメントへの応答です。Silverlight / WPFは短期（2〜5年）で実行可能であることに同意します。ただし、私たちが作成するアプリケーションの寿命は非常に長い可能性があります（10〜20年以上）。そのため、特定のテクノロジーの長期的な存続可能性が私たちの懸念事項です。また、Silverlight / WPF開発に関心のある開発者がコミュニティによって「死んだ」と見なされると、それらの開発者を見つけることがますます困難になるという懸念があります。私は自分の選択肢を理解し、目を開けて決断をしたいだけです。

15 architecture  enterprise-architecture  windows-8  forward-compatibility 

私は多くのユーザーをサポートするアプリケーションを開発しています。問題は、クライアント/ユーザーを認証する方法がわからないことです。 私はhttp://quickblox.com/のようなアプリを構築しています。そこでユーザーに資格情報を提供し、ユーザーはそれらを使用してユーザー名とパスワードを入れて認証を取得できないNアプリケーションを構築します。 それが次のようになると仮定しましょう。（QuickBloxと同じように） 1.ユーザーが私のWebサイトでアカウントを作成します。 2.ユーザーはN個のAPIキーを作成し、資格情報を秘密にすることができます。（複数のアプリの場合） 3.ユーザーは、アプリケーション（Android、iOS、Javascriptなど）でこれらの資格情報を使用して、REST APIと通信します。（REST APIには読み取りおよび書き込みアクセスがあります。） 私の懸念？ ユーザーは自分が作成したアプリケーションに資格情報（APIキーと秘密キー）を入れます。誰かがこれらのキーを取得して、ユーザーをまねようとするとどうなりますか？（APKを逆コンパイルするか、JavaScriptコードを直接調べます。 どこか間違ってる？この3つのレベルのユーザーメカニズムを設計するのは混乱しています。

14 design-patterns  architecture  api-design  authentication  enterprise-architecture