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

マイクロサービスアーキテクチャの各サービスには独自のデータベースが必要であることを理解しています。しかし、独自のデータベースを持つということは、実際には、同じデータベースインスタンス内に別のデータベースを単に持つことを意味しますか、それとも文字通り別のデータベースインスタンスを含むことを意味しますか？ これにより、私はデータベースの共有を意味するのではなく、これはノー・ノーであり、むしろデータベースのインスタンスです。 たとえば、AWSを使用していて3つのサービスがある場合、単一のRDSインスタンスで各サービスに3つのデータベースを作成しますか、3つのサービスのそれぞれで独立して使用されるデータベースを含む3つのRDSインスタンスを作成しますか？ 単一のRDSインスタンスで複数のデータベースを使用することをお勧めする場合、次の理由により、独立したサービスを持つという目的を無効にします。 RDSインスタンスのリソースはサービス間で共有されます。特定の時間にデータベースの使用量が多い可能性のあるサービスAは、同じRDSインスタンス上で異なるデータベースを使用するサービスBに影響しますか？ すべてのサービスは、そのRDSインスタンスのデータベースバージョンに依存します。

50 architecture  database  microservices  service 

理由はわかりませんが、リフレクションを使用するときは常に「ごまかし」のような気がします-おそらく、自分が取っているパフォーマンスヒットのせいでしょう。 私の一部は、それがあなたが使用している言語の一部であり、あなたがしようとしていることを達成できるなら、なぜそれを使用しないのかと言います。私の他の部分は、リフレクションを使用せずにこれを行うことができる方法がある必要があると言います。多分それは状況次第だと思います。 リフレクションを使用する際に注意する必要のある潜在的な問題は何ですか？従来の解決策を見つけようとするのにどれだけの労力を費やす価値がありますか？

49 design  programming-practices  architecture  code-quality 

最近、デザインにマネージャークラスをたくさん持つのは悪いことだと思い始めました。このアイデアは説得力のある議論をするには十分に成熟していませんが、いくつかの一般的なポイントがあります： 「マネージャー」に大きく依存しているシステムを理解することは、私にとってはるかに難しいことがわかりました。これは、実際のプログラムコンポーネントに加えて、マネージャの使用方法と理由を理解する必要があるためです。 マネージャーは、多くの場合、プログラマーがプログラムJust Work TMを作成する方法を見つけることができず、マネージャークラスに依存してすべてが正常に動作する必要がある場合など、設計の問題を軽減するために使用されるようです。 もちろん、飼い葉sは良いことができます。明らかな例は、EventManager私のお気に入りの構造の1つです。：P私のポイントは、マネージャーが多くの時間を使いすぎているように見えることであり、プログラムアーキテクチャの問題を隠す以外の正当な理由はありません。 マネージャークラスは本当に悪いアーキテクチャの兆候ですか？

49 design  architecture 

スタートアップの唯一の開発者として、私はアプリケーションのアーキテクチャとフレームワークで多くの決定を下すことができた贅沢がありました。 4年前に早急に買収し、5人でチームを組みました。多くの場合、ワイルドウエストのように感じます。設計上の決定をする人は、彼らを喜ばせます：1つの場所でDB型の整数と列挙、別の場所で文字列、問題のこのフレームワーク、次に同じ問題の別のフレームワークなど。 一貫性を強化するにはどうすればよいですか？それは私にとって重要だと感じていますが、私のチームのメンバーは「うまくいけばうまくいく」方法論に加入しているようです。 私の質問の大部分は、このような標準を期待することは私にとって非現実的ですか？独創性を抑える独裁者として出会うというアイデアに苦労していますが、彼らがやりたいことはスケーラブルではないようです。

49 architecture  management  team-building 

これを求める別の方法は次のとおりです。なぜプログラムはモノリシックになる傾向があるのですか？ Mayaのようなアニメーションパッケージのようなものを考えています。人々はさまざまなワークフローに使用します。 アニメーション機能とモデリング機能を独自の個別のアプリケーションに分割し、それらの間でファイルをやり取りして個別に開発した場合、それらの保守は容易ではないでしょうか？

48 design  architecture  maintainability  application-design 

一般的な質問ではありますが、C ++のような言語はコンストラクターの実行、メモリ管理、未定義の動作などに関して異なるセマンティクスを持っていることを知っているので、私のスコープはむしろC＃です。 誰かが私に興味深い質問をしましたが、それは私には簡単には答えられませんでした。 クラスのコンストラクターが終わりのないループ（つまり、ゲームループ）を開始できるようにするのは悪い設計と見なされるのはなぜですか（またはまったくそうではないのですか）。 これによって破られるいくつかの概念があります： 最小限の驚きの原則のように、ユーザーはコンストラクターがこのように動作することを期待していません。 ユニットテストは、このクラスを作成したり、ループを終了しないため挿入したりできないため、より困難です。 ループの終わり（ゲームの終わり）は、概念的にはコンストラクターが終了する時間であり、これも奇妙です。 技術的には、このようなクラスにはコンストラクター以外のパブリックメンバーがありません。これにより、理解が難しくなります（特に実装が利用できない言語の場合） そして、技術的な問題があります： コンストラクターは実際には終了しないため、GCで何が起こるのでしょうか？このオブジェクトは既にGen 0ですか？ このようなクラスから派生することは、不可能であるか、少なくとも非常に複雑です。これは、基本コンストラクターが決して返さないため そのようなアプローチでより明らかに悪いまたは不正な何かがありますか？

47 c#  architecture 

私はEvansによるドメイン駆動設計を読んでおり、階層アーキテクチャについて議論している部分にいます。アプリケーション層とドメイン層は異なり、別々にする必要があることに気付きました。私が取り組んでいるプロジェクトでは、それらは混ざり合っており、本を読むまで違いを伝えることはできません（そして、今では私にとって非常に明確だとは言えません）。 私の質問は、どちらもアプリケーションのロジックに関するものであり、技術的側面とプレゼンテーションの側面はきれいであると想定されているため、これら2つの境界線を引くことの利点は何ですか？

47 architecture  domain-driven-design 

コンピューターサイエンスの非同期と同期という言葉の意味は何ですか？ 単語の意味をグーグルで検索すると、次のものが得られます。 非同期：存在しないか、同時に発生しません。 同期：既存または同時に発生します。 しかし、プログラミングやコンピューターサイエンスで反対の意味を伝えるために使用されているようです。 HTML非同期属性は、HTMLがまだ解析中またはダウンロード中であっても、ダウンロードされるとすぐにスクリプトが実行されることを意味します。つまり、スクリプトとHTMLの両方のプロセスが存在し、同時に発生します。 これらの用語は、コンピューターサイエンスで反対の意味を伝えるために使用されていますか、それとも私がポイントを逃していますか？

46 architecture  terminology 

さて、タイトルは少しクリックされていますが、真剣に私は言いました、しばらくキックを求めないでください。私は、メソッドが真のオブジェクト指向の方法でメッセージとして使用されることを奨励する方法が好きです。しかし、これには頭の中のガタガタする問題があります。 よく書かれたコードは、オブジェクト指向の原則と機能の原則を同時に満たすことができると疑うようになりました。私はこれらの考えを調和させようとしています、そして、私が着陸した大きなこだわりポイントはreturnです。 純関数には次の2つの性質があります。 同じ入力で繰り返し呼び出すと、常に同じ結果が得られます。これは、不変であることを意味します。その状態は一度だけ設定されます。 副作用はありません。呼び出しによって引き起こされる唯一の変更は、結果の生成です。 それでは、return結果を伝える方法として使用することを誓った場合、どうすれば純粋に機能的になりますか？ TELLは、聞いていない、いくつかの副作用を検討するものを使用してアイデアの作品を。オブジェクトを扱うとき、その内部状態については尋ねません。何をする必要があるかを伝え、その内部状態を使用して、私がそれを行うように指示したことで何をすべきかを見つけます。一度言ったら、何をしたのかは聞かない。私は、それがするように言われたことについて何かをしたと思っています。 Tell、Den's Askは単にカプセル化の別の名前以上のものだと思います。私が使うとき、私はreturn何が私を呼んだのかわかりません。私はそれのプロトコルを話すことができません、私はそれが私のプロトコルに対処することを強制する必要があります。多くの場合、これは内部状態として表されます。公開されているものが正確な状態ではない場合でも、通常は状態と入力引数に対して実行される計算にすぎません。応答するインターフェースがあると、結果を内部状態や計算よりも意味のあるものにマッサージする機会が与えられます。それはメッセージパッシングです。この例を参照してください。 昔、ディスクドライブには実際にディスクが搭載されていて、指で触れるにはホイールが冷たすぎるときに親指ドライブが車で行っていたものでした。void swap(int *first, int *second)とても便利に見えましたが、結果を返す関数を書くことが奨励されました。それで私はこれを信仰で心に留め、それを追い始めました。 しかし、今では、オブジェクトを構築する方法によって結果の送信先を制御できるアーキテクチャを構築する人々がいます。以下に実装例を示します。出力ポートオブジェクトを注入することは、出力パラメーターの考え方に似ています。しかし、それが、tell-don't-askオブジェクトが他のオブジェクトに何をしたかを伝える方法です。 副作用について最初に学んだとき、それを出力パラメーターのように考えました。私たちは、仕事のいくつかを驚くべき方法で、つまりreturn result慣習に従わないことによって人々を驚かせないように言われていました。確かに、副作用が発生する並列非同期スレッドの問題が山積みになっていることはわかっていますが、戻り値は実際には単に結果をスタックにプッシュしたままにしておくため、呼び出されたものは後でポップオフできます。それだけです。 私が本当に求めていること： あるreturnすべてのその副作用の悲惨さを回避し、ロックせずに、スレッドの安全性を取得する唯一の方法は、など、または私は従うことができます聞いていない、言う純粋に機能的な方法で？

45 object-oriented  architecture  functional-programming  side-effect 

私は多くの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 

多くの企業が「逆ドメイン名」の名前空間を使用していることに気づきました。そのプラクティスがどこから始まったのか、なぜ続くのか興味があります。それは単純な練習のために単に継続するのですか、それとも私がここで見逃しているかもしれない顕著なアーキテクチャの概念がありますか？ また、のような質問注意：https://stackoverflow.com/questions/189209/do-you-really-use-your-reverse-domain-for-package-naming-in-javaをその答えのようなもの、私の質問はありません100 ％ （気分が良くなったら、javascriptのネームスペース作業にそれを使用すべきかどうか本当に興味がありますが、その時と理由についてはもっと興味があります。 bene： "window"） フォルダーとファイルに拡張するこのプラクティスの例：

45 architecture  namespace 

卒業（2005年後半）以来、私はc ++ソフトウェアエンジニアと同じ会社で働いていました。1年前、私はソフトウェアアーキテクトとして昇進しましたが、資格の取得とバグの修正、レベル2サポートにますます関与するようになりました。 私の時間の50％は、Notepad ++でソフトウェアログを分析し、何が問題だったのかを把握するために費やしました。30％が他のバグを修正し、残りの（存在する場合）開発者のスパゲッティコードをレビューします。 私はこの製品を嫌い、この会社の出口戦略について考え始めました。 この状況で私にできることは何だと思いますか？他のソフトウェアアーキテクトはまだコードのバグを修正していますか？

45 architecture  teamwork  software 

相互に呼び出す複数のサービス（フロントエンド->バックエンド->ストレージなど）で構成されるシステムの場合、「ダウンストリーム」または「アップストリーム」サービスなどの用語を使用している人がよくいました。これらがどの方向を意味するのかは明確ではありません。データは両方向に流れます。リクエストはより多くのユーザー向けからより多くのバックエンドサービスに流れますが、レスポンスは反対方向に流れるため、どちらかの方法で議論できるように思えます

45 architecture  terminology 

まず、これは軽視されている質問/領域であるように思われるので、この質問を改善する必要がある場合は、他の人に利益をもたらすことができる素晴らしい質問にしてください！試してみたいアイデアだけでなく、この問題を解決するソリューションを実装した人々からのアドバイスやヘルプを探しています。 私の経験では、アプリケーションには2つの側面があります。主にドメイン駆動型で、ユーザーがドメインモデル（アプリケーションの「エンジン」）とやり取りする「タスク」側と、ユーザーがタスク側で何が起こるかに基づいてデータを取得します。 タスク側では、リッチなドメインモデルを備えたアプリケーションにはドメインモデルのビジネスロジックが必要であり、データベースは主に永続化のために使用する必要があることは明らかです。懸念の分離、すべての本はそれについて書かれています、私たちは何をすべきか、素晴らしいを知っています。 レポート側についてはどうですか？データウェアハウスは受け入れ可能ですか、それともデータベースとビジネスそのものにビジネスロジックを組み込んでいるため、設計が悪いのでしょうか。データベースのデータをデータウェアハウスデータに集約するには、データにビジネスロジックとルールを適用している必要があります。そのロジックとルールはドメインモデルからではなく、データ集約プロセスからのものです。それは間違っていますか？ 私は、ビジネスロジックが広範囲にわたる大規模な財務およびプロジェクト管理アプリケーションに取り組んでいます。このデータのレポートを作成するとき、レポート/ダッシュボードに必要な情報を取得するために多くの集計を行うことが多く、集計には多くのビジネスロジックが含まれています。パフォーマンスのために、高度に集約されたテーブルとストアドプロシージャを使用してこれを行っています。 例として、アクティブなプロジェクトのリストを表示するためにレポート/ダッシュボードが必要だとしましょう（10,000個のプロジェクトを想像してください）。各プロジェクトには、次のような一連のメトリックが必要です。 総予算 これまでの努力 燃焼速度 現在の燃焼速度での予算枯渇日 等 これらのそれぞれには、多くのビジネスロジックが含まれます。そして、私は単に数字の乗算やいくつかの単純なロジックについて話しているのではありません。予算を得るために話しているのは、各従業員の時間（一部のプロジェクトでは、他のプロジェクトでは乗数があります）に1つずつ、500の異なるレートのレートシートを適用し、費用や適切なマークアップなどを適用する必要があることですロジックは広範です。クライアントにとって妥当な時間内にこのデータを取得するには、多くの集約とクエリのチューニングが必要でした。 これは最初にドメインを介して実行する必要がありますか？パフォーマンスはどうですか？単純なSQLクエリを使用しても、クライアントが妥当な時間内に表示するのに十分な速度でこのデータを取得することはほとんどありません。これらすべてのドメインオブジェクトをリハイドレートし、アプリケーションレイヤーでデータを混合および照合して集約する場合、またはアプリケーションでデータを集約しようとする場合、クライアントにこのデータを十分に速く取得しようとすることは想像できません。 これらのケースでは、SQLはデータの処理に優れているように思われますが、使用しないのはなぜですか？ただし、ドメインモデルの外部にビジネスロジックがあります。ドメインモデルおよびレポート集計スキームでビジネスロジックを変更する必要があります。 ドメイン駆動設計と優れた実践に関して、アプリケーションのレポート/ダッシュボード部分をどのように設計するかについて、私は本当に困っています。 MVCはデザインフレーバーデュジュールであり、現在のデザインで使用しているため、MVCタグを追加しましたが、レポートデータがこのタイプのアプリケーションにどのように適合するかわかりません。 本、デザインパターン、グーグルのキーワード、記事など、この分野での助けを探しています。このトピックに関する情報が見つかりません。 編集と別の例 今日出会った別の完璧な例。顧客が顧客営業チームのレポートを望んでいる。彼らは単純なメトリックのように見えるものを望んでいます： 各営業担当者の現在までの年間売上はいくらですか？ しかし、それは複雑です。各販売員は複数の販売機会に参加しました。勝った人もいなかった人もいます。各販売機会には、それぞれの役割と参加ごとに、販売に対するクレジットの割合が割り当てられた複数の販売員がいます。それでは、このためにドメインを通過することを想像してください。すべての営業担当者のデータベースからこのデータを引き出すために必要なオブジェクトの再水和の量： すべての取得SalesPeople- > それぞれが得るために彼らのSalesOpportunities- > 各販売の彼らの割合を取得し、その販売量を算出するために 、すべての彼らの最大の追加SalesOpportunity販売量を。 そして、それは1つのメトリックです。または、迅速かつ効率的に実行し、高速に調整できるSQLクエリを作成できます。 編集2- CQRSパターン CQRSパターンについて読んだことがありますが、興味深いことに、Martin Fowlerもテストされていないと言います。それで、過去にこの問題はどのように解決されましたか。これは、何らかの点で全員が直面していなければなりません。成功の実績を持つ確立されたアプローチまたは使い古されたアプローチとは何ですか？ 編集3-レポートシステム/ツール このコンテキストで考慮すべきもう1つのことは、レポートツールです。Reporting Services / Crystal Reports、Analysis Services、Cognoscentiなどはすべて、SQL /データベースからのデータを想定しています。これらのデータが後であなたのビジネスに届くとは思いません。それでも、彼らと彼らのような人々は、多くの大規模システムのレポートの重要な部分です。これらのシステムのデータソースやレポート自体にもビジネスロジックがある場合、これらのデータは適切に処理されますか？

44 mvc  architecture  domain-driven-design  reporting  data-warehouse 

バックグラウンド ： 私はAndroidアプリでボブおじさんのクリーンアーキテクチャを使用しようとしています。私はそれを行う正しい方法を示しようとしている多くのオープンソースプロジェクトを研究し、RxAndroidに基づいた興味深い実装を見つけました。 気づいたこと： すべてのレイヤー（プレゼンテーション、ドメイン、およびデータ）には、同じエンティティ（UMLを話す）のモデルクラスがあります。さらに、データが境界を越えたとき（レイヤーから別のレイヤーへ）にオブジェクトを変換するマッパークラスがあります。 質問 ： すべてのCRUD操作が必要な場合、すべてのモデルクラスが同じ属性で終わることがわかっている場合、すべてのレイヤーにモデルクラスが必要です。または、クリーンアーキテクチャを使用する場合のルールまたはベストプラクティスですか？

44 java  architecture  android  clean-code  layers