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

UUIDの要点は本当にわかりません。私は衝突の確率が事実上nilであることを知っていますが、事実上nilは不可能に近いものではありません。 UUIDを使用する以外に選択肢のない例を誰かが示すことができますか？私が見たすべての用途から、UUIDなしの代替設計を見ることができます。確かに設計は少し複雑かもしれませんが、少なくともゼロ以外の失敗の確率はありません。 UUIDは、グローバル変数のような匂いがします。グローバル変数がより単純な設計を実現する方法はたくさんありますが、それは単に怠惰な設計です。

123 architecture  uuid 

複数の言語とロケールで利用できるようにする必要があるアプリを作成しています。 私の質問は、純粋に技術的なものではなく、アーキテクチャと、人々がこの問題を解決するために実際に本番で使用しているパターンについてです。そのための「クックブック」はどこにも見つからなかったので、お気に入りのQ / A Webサイトに移動します:) ここに私の要件があります（それらは本当に「標準」です）： ユーザーは言語を選択できます（簡単です） 言語を変更すると、インターフェースは自動的に新しく選択された言語に翻訳されます 現時点では、数値や日付などのフォーマットについてあまり心配していません。文字列を翻訳するだけの簡単な解決策が欲しいのですが ここに私が考えることができる可能な解決策があります： 各コンポーネントは個別に翻訳を処理します つまり、各コンポーネントには、翻訳された文字列と一緒に、たとえばen.json、fr.jsonなどの一連のファイルがあります。また、選択した言語に応じて値を読み取るのに役立つヘルパー関数。 プロ：Reactの哲学を尊重し、各コンポーネントは「スタンドアロン」です 短所：すべての翻訳をファイルに一元化することはできません（たとえば、誰かに新しい言語を追加させるため） 短所：すべての流血のコンポーネントとその子供に、現在の言語を小道具として渡す必要があります 各コンポーネントは、小道具を介して翻訳を受け取ります したがって、彼らは現在の言語を認識していません。たまたま現在の言語と一致する小道具として文字列のリストを取得します プロ：これらの文字列は「上から」来るため、どこかに集中させることができます 短所：各コンポーネントが翻訳システムに関連付けられているため、コンポーネントを再利用するだけではなく、毎回正しい文字列を指定する必要があります。 小道具を少しバイパスし、おそらくコンテキストの事を使用して現在の言語を伝えます プロ：それはほとんど透過的で、現在の言語や翻訳をプロップを介して常に渡す必要はありません 短所：使用するのが面倒に見える 他にアイデアがあれば、言ってください！ どうやってやるの？

119 architecture  internationalization  reactjs  translation  redux 

インターネットでデザインパターンについて読むとき、3つのカテゴリがあることに注意してください。 創造的 構造的 ふるまい しかし、ソフトウェアのアーキテクチャを作成するときは、MVP、MVC、またはMVVMについて考えます。 たとえば、作成パターンの中からシングルトンパターンを見つけましたが、MPVでもシングルトンを使用しました。 だから私の質問は：デザインパターンは製品の全体的な構造ですか？ はいの場合、シングルトンはどのように設計パターンになりますか？アプリケーションのどこでも使用できるからです。基本的に、メモリ内に一度に1つのインスタンスを作成することだけに制限されていますが、この概念はソフトウェアの設計方法を定義していませんか？ そうでない場合は、MVP、MVC、MVVMの3つのパターンカテゴリはどこにあるのでしょうか。そして、ソフトウェアの設計とアーキテクチャの違いは何ですか？

119 design-patterns  architecture 

高いスケーラビリティでは、ここで機能フラグについて言及しています。 スケーラビリティにとって有害な5つのこと、「5。機能フラグの欠如」 機能フラグとは正確には何ですか？

115 architecture  scalability 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 5年前休業。 この質問を改善する 最近、共同作業する複数のマイクロサービスをデプロイするために、Docker Composeでいくつかの実験を行っています。マイクロサービスが提供する多くの利点を見ることができ、それらを管理するための優れたツールセットがあるので、マイクロサービスワゴンに飛び込むことはそれほど難しくないと思います。 しかし、私はElixirも実験しており、それ自体がもたらす利点をとても気に入っています。それはあなたのコードを複数の分離されたアプリケーションに詰め込むことを奨励し、ホットコードのアップグレードをサポートすることを考えると、どのようにdockerをelixir（またはそのことについてはerlang）と混合しますか？ たとえば、dev-prodパリティを提供するためにdockerを使用したい場合、elixirはそれにどのように適合しますか？Dockerコンテナーは不変であることを考えると、ホットコードのアップグレードを実行できなくなりますよね？青/緑のデプロイメントまたはカナリアリリースについてはどうですか？ つまり、Elixirでマイクロサービスを作成して、他の言語で作成されているかのようにそれらを使用することができます。ポリグロティズムは、いずれにせよマイクロサービスの利点の1つですが、OTPプラットフォームを使用することの完全な利点は得られません。純粋なコラボレーティブerlangアプリケーションは、中間のキューを使用して異なる（または異なる）言語で記述されたマイクロサービス間で通信するよりもはるかに最適であると推測します。

109 architecture  erlang  docker  elixir  microservices 

マシンのエンディアンを決定する1行のマクロ定義はありますか？次のコードを使用していますが、マクロに変換するには時間がかかりすぎます。 unsigned char test_endian( void ) { int test_var = 1; unsigned char *test_endian = (unsigned char*)&test_var; return (test_endian[0] == 0); }

107 c  architecture  macros  endianness 

複雑な単一ページのJS Webアプリケーションをクライアント側でどのように構成する必要がありますか？具体的には、モデルオブジェクト、UIコンポーネント、コントローラー、サーバーの永続性を処理するオブジェクトの観点から、アプリケーションをきれいに構造化する方法に興味があります。 MVCは最初は適合しているように見えました。しかし、UIコンポーネントがさまざまな深さでネストされている場合（それぞれが独自の方法でデータをモデル化するために作用/反応し、それぞれがイベントを生成して、それら自体が直接処理する場合と処理しない場合があります）、MVCをきれいに適用できるようには見えません。（ただし、そうでない場合は修正してください。） - （この質問の結果、ajaxの使用に関する 2つの提案が出されました。これは、最も簡単な1ページアプリ以外には明らかに必要です。）

99 javascript  design-patterns  web-applications  architecture  singlepage 

現在のところ、この質問はQ＆A形式には適していません。私たちは回答が事実、参考文献、または専門知識によってサポートされることを期待しますが、この質問はおそらく議論、議論、投票、または拡張された議論を誘います。この質問を改善でき、再開できると思われる場合は、ヘルプセンターにアクセスしてください。 8年前に閉鎖。 私が見る限り、ソリューションアーキテクトはアプリケーションアーキテクトの単なる「マーケティング」用語です。それは正しいですか、それとも実際には役割が異なっていますか？もしそうなら、どうですか？ はい、StackOverflowとGoogleの両方でこれを検索しました。

95 architecture  definition 

私は常にリポジトリパターンを使用していましたが、最新のプロジェクトでは、それの使用と「作業単位」の実装を完璧にできるかどうかを確認したいと思いました。掘り始めると、「本当に必要なのか」という疑問を持ち始めました。 これはすべて、Stackoverflowに関するいくつかのコメントから始まります。AyendeRahienのブログへの投稿への痕跡が2つあります。 リポジトリは新しいシングルトンです ask-ayende-life-without-repositories-the-they-worth-living これはおそらくいつまでも話される可能性があり、アプリケーションによって異なります。私が知りたいのは、 このアプローチはEntity Frameworkプロジェクトに適していますか？ このアプローチを使用して、ビジネスロジックはまだサービスレイヤー、または拡張メソッドにありますか（以下で説明するように、拡張メソッドはNHibセッションを使用しています）。 これは、拡張メソッドを使用して簡単に実行できます。クリーンでシンプルで再利用可能。 public static IEnumerable GetAll( this ISession instance, Expression<Func<T, bool>> where) where T : class { return instance.QueryOver().Where(where).List(); } このアプローチをNinjectDIとして使用してContext、インターフェイスを作成し、それをコントローラーに挿入する必要がありますか？

95 entity-framework  design-patterns  architecture  aop  repository-pattern 

私が個人的に精通しているアーキテクチャ（x86、6502など）では、スタックは通常下向きに成長します（つまり、スタックにプッシュされるすべてのアイテムは、増加したSPではなく減少したSPになります）。 これの歴史的根拠について疑問に思っています。統合されたアドレススペースでは、スタックをデータセグメントの反対側から（たとえば）開始するのが便利なので、2つの側が中央で衝突した場合にのみ問題が発生します。しかし、なぜスタックは伝統的にトップの部分を獲得するのでしょうか？特に、これが「概念」モデルとは正反対であることを考えると、 （また、6502アーキテクチャーでは、単一の256バイトのページにバインドされているにもかかわらず、スタックも下方向に大きくなることに注意してください。この方向の選択は任意です。）

95 architecture  stack  history 

Spring Core認定について勉強しています。SpringがBeanのライフサイクルをどのように処理するか、特にBeanポストプロセッサについては疑問があります。 だから私はこのスキーマを持っています： それが何を意味するかは私にはかなり明らかです： 次の手順は、Bean定義のロード段階で行われます。 @Configurationのクラスが処理され、および/または@Componentsがスキャンされ、および/またはXMLファイルが解析されます。 BeanFactoryに追加されたBean定義（それぞれはそのIDでインデックスが付けられます） 呼び出された特別なBeanFactoryPostProcessor Beanは、任意のBeanの定義を変更できます（たとえば、プロパティー-プレースホルダー値の置換用）。 次に、次の手順がBean作成フェーズで行われます。 各Beanはデフォルトで積極的にインスタンス化されます（依存関係が挿入された正しい順序で作成されます）。 依存関係の注入後、各Beanは後処理フェーズを通過し、追加の構成と初期化が行われる可能性があります。 後処理後、Beanは完全に初期化され、使用できる状態になります（コンテキストが破棄されるまで、IDによって追跡されます） わかりました、これは私にはかなり明確であり、次の2種類のBeanポストプロセッサがあることも知っています。 初期化子：指示された場合はBeanを初期化します（つまり、@ PostConstruct）。 そしてすべての残り：追加の設定を可能にし、それが初期化工程の前または後に実行可能 そして私はこのスライドを投稿します： したがって、イニシャライザ Beanポストプロセッサが何を行うかは非常に明確です（これらは@PostContructアノテーションが付けられたメソッドであり、セッターメソッドの直後に（つまり、依存関係の注入後に）自動的に呼び出されます）。いくつかの初期化バッチを実行します（前の例のようにキャッシュに入力します）。 しかし、他のBeanポストプロセッサを正確に表すものは何でしょうか。これらのステップが初期化フェーズの前または後に実行されるとはどういう意味ですか？ そのため、私のBeanがインスタンス化され、その依存関係が注入されるため、初期化フェーズは（@PostContructアノテーション付きメソッドの実行によって）完了します。初期化フェーズの前にBean Post Processorが使用されているとはどういう意味ですか？@PostContructアノテーション付きメソッドの実行前に発生するということですか？これは、依存関係の注入前（セッターメソッドが呼び出される前）に発生する可能性があることを意味しますか？ そして、それが初期化ステップの後に実行されると言うとき、私たちは正確にどういう意味ですか。@PostContructアノテーション付きメソッドの実行後に発生することを意味しますか？ @PostContructアノテーション付きメソッドが必要な理由を頭の中で簡単に理解できますが、他の種類のBeanポストプロセッサの典型的な例を理解できません。

94 spring  spring-mvc  architecture 

昨日、問題なくアプリをレビューのために送りました。その後、修正の余地がほとんどないことに気づき（マップの最大ズームレベルを19から18に変更しました）、iTunes Connectからバイナリを削除し、再送信を試みました。 今、私はこの警告を受けています： 私のアーキテクチャは次のとおりなので、理由がわかりません： アーキテクチャ：armv7 有効なアーキテクチャ：armv6、armv7、armv7s、arm64 アプリはシミュレータで正常に実行されます。警告で推奨されているように標準アーキテクチャ（armv7、arm64）を使用しようとすると、アプリがビルドされず、次のようになります。 アーキテクチャx86_64の未定義のシンボル ld：アーキテクチャx86_64のシンボルが見つかりません 私はlib route-meを使用しており、同じアーキテクチャ設定を設定しています。

91 ios  architecture  app-store  xcode6  arm64 

現在のところ、この質問はQ＆A形式には適していません。私たちは回答が事実、参考文献、または専門知識によってサポートされることを期待しますが、この質問はおそらく議論、議論、投票、または拡張された議論を誘います。この質問を改善でき、再開できると思われる場合は、ヘルプセンターにアクセスしてください。 7年前休業。 私は特に、ファットモデルと細いコントローラーのアプローチを支持する多くのブログを読んでいます。Railsキャンプ。その結果、ルーターは基本的に、どのコントローラーでどのメソッドを呼び出すかを理解しているだけであり、すべてのコントローラーメソッドは、モデルの対応するメソッドを呼び出してビューを表示します。だから私はここで私が理解できない2つの懸念を持っています： コントローラーとルーターは、ルートに基づいて神のようなモデルでメソッドを呼び出す以外に、実際にはそれほど異なるタスクを実行していません。 モデルがやりすぎです。電子メールの送信、関係の作成、他のモデルの削除と変更、タスクのキューイングなど。基本的に、データのモデリングと処理に関係するかどうかに関係なく、すべてを実行することになっている神のようなオブジェクトがあります。 どこに線を引くのですか？これは単に神のパターンに該当するのではないですか？

91 model-view-controller  design-patterns  architecture  god-object 

ドメイン駆動設計の一部で、詳細があまり詳しくないようですが、ドメインモデルをインターフェイスから分離する方法と理由です。これは良い習慣だと同僚に納得させようとしていますが、あまり進んでいないようです... プレゼンテーションレイヤーとインターフェイスレイヤーで、好きな場所でドメインエンティティを使用します。ドメインレイヤーをインターフェイスレイヤーから分離するために表示モデルまたはDTOを使用する必要があると私が主張するとき、彼らは、維持するUIオブジェクトがあるため、そのようなことを行うことでビジネス価値が見られないと反論します。元のドメインオブジェクトと同様に。 だから私はこれをバックアップするために使用できるいくつかの具体的な理由を探しています。具体的には： プレゼンテーション層でドメインオブジェクトを使用しないのはなぜですか？ （答えが明白なものである場合、「デカップリング」、それからこれがこの文脈で重要である理由を説明してください） ドメインオブジェクトをインターフェイスから分離するために、追加のオブジェクトまたは構成を使用する必要がありますか？

85 design-patterns  architecture  domain-driven-design  presentation-layer  data-transfer-objects 

クローズ。この質問はもっと焦点を合わせる必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てるようにします。 5年前に閉鎖されました。 この質問を改善する 私が苦労していることの1つは、コードを書く前にアプリケーションのアーキテクチャを計画することです。 アプリケーションが何をする必要があるかを絞り込むための要件を収集することを意味するのではなく、クラス全体、データ、およびフロー構造をレイアウトするための良い方法を効果的に考え、それらの考えを繰り返して、信頼できる計画を立てることを意味します。 IDEを開く前にアクションを念頭に置いてください。現時点では、IDEを開いて空白のプロジェクトを作成し、ビットとボブの作成を開始して、そこからデザインを「成長」させるのは簡単です。 私はUMLを収集することはこれを行う1つの方法ですが、私はそれを経験したことがないので、ちょっと曖昧に思えます。 コードを書く前に、アプリケーションのアーキテクチャをどのように計画しますか？UMLが進むべき道である場合、小さなアプリケーションの開発者に簡潔で実用的な紹介をお勧めできますか？ ご意見ありがとうございます。

84 language-agnostic  architecture  oop