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

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 5年前休業。 私はウェブサイトの宣伝文を読み、申し立てられている利点に感銘を受けることができますが、TOGAF（または他の）アーキテクチャフレームワークをフォローしている人や誰とも働いていません。 私たちの組織は、現在かなりシャンボリックな設計および開発モデルから、現代​​の構造化されたプロセスに近づくものへの移行に専念することを宣言しています。 TOGAFのようなものは、世界クラスのエンタープライズ開発環境（！）を達成するのに役立つと言われていますが、ここで誰もが、卸売りの採用がもたらす実際のメリットを理解していません。同じを達成するために必要な痛み。 TOGAFまたはそれに類似した組織でのレスリングコントロールの使用経験はありますか？フレームワークを使用することで何かメリットがあると思いますか？ 編集：説明のために、TOGAFは「オープングループアーキテクチャフレームワーク」であり、エンタープライズアーキテクチャを開発するための詳細な方法とツールセットです。参照：http : //www.opengroup.org/architecture/togaf8-doc/arch/

9 architecture 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 6年前休業。 ソフトウェアアーキテクチャのスキルを向上させる最良の方法は何ですか？私たちは大学でデザインパターンを教えられましたが、シンプルでわかりやすい例を含む本がたくさんありますが、それらを除いて、どうすれば優れた建築を学ぶことができますか？つまり、どのようにして優れた建築家に進化するのでしょうか。前提条件は何ですか？

9 architecture  skills 

問題は、現在のスレッドがメインスレッドであることを表明する単体テストを記述することには意味があるのでしょうか。長所短所？ 最近、サービスのコールバックのために現在のスレッドをアサートする単体テストを見ました。いいアイデアだとは思いませんが、もっと統合テストだと思います。私の意見では、単体テストはメソッドを個別にアサートする必要があり、サービスの利用者の性質については知らないはずです。 たとえば、iOSでは、このサービスのコンシューマーは、デフォルトでメインスレッドでコードを実行するための制約を持つUIであることが意図されています。

8 architecture  unit-testing  object-oriented-design  multithreading  ios 

私の理解では、進化的アーキテクチャは、アーキテクチャを簡単に変更できるようにすることです。現在、アーキテクチャーは多くの場合、後で変更するのが難しいため、早期に正しく取得する必要があるものとして定義されています。 これはどのように組み合わされますか？進化的アーキテクチャとアーキテクチャの量を最小限に抑えることの間に違いはありますか？

8 design  architecture  agile  architectural-patterns 

シングルトンパターンとそれがどのように「悪い」のかについては、クラスをテストするのが難しくなるので避けてきました。シングルトンを依存性注入に置き換える方法を説明した記事をいくつか読んだことがありますが、それは不必要に複雑に思えます。 これがもう少し詳しく私の問題です。私はReact Nativeを使用してモバイルアプリを構築しています。サーバーと通信し、データを取得し、データを投稿し、ログインを処理するRESTクライアントを作成します（ログイントークンを保存し、ログイン後にリクエストごとに送信します）。 私の最初の計画は、アプリが最初にログインに使用し、必要に応じて資格情報の送信を要求するシングルトンオブジェクト（RESTClient）を作成することでした。DIのアプローチは本当に複雑に思えます（おそらくDIを使用したことがないためです）が、このプロジェクトを最大限に活用して、ここで最善を尽くしたいと思います。提案やコメントは大歓迎です。 編集：私は今、自分の質問の言葉遣いが不十分であることに気づきました。RNでシングルトンパターンを回避する方法についてのガイダンスが必要でした。幸運にも、サミュエルは私が望んでいたような答えをくれました。私の問題は、シングルトンパターンを避けてDIを使用したかったのですが、React Nativeで実装するのは本当に複雑に思えました。さらに調査を行い、Reactsコンテキストシステムを使用して実装しました。 ここに興味のある人のために、私はそれをしました。私が言ったように、私はプロップのようなものであるRNのコンテキストを使用しましたが、それはすべてのコンポーネントに伝搬されます。 ルートコンポーネントでは、次のような必要な依存関係を提供します。 export default class Root extends Component { getChildContext() { restClient: new MyRestClient(); } render() {...} } Root.childContextTypes = {restClient: PropTypes.object}; これで、restClientは、ルートの下のすべてのコンポーネントで使用できます。このようにアクセスできます。 export default class Child extends Component { useRestClient() { this.context.restClient.getData(...); } render() {...} } Child.contextTypes = {restClient: PropTypes.object} これにより、オブジェクトの作成がロジックから効果的に離れ、RESTクライアントの実装がコンポーネントから切り離されます。

8 design-patterns  architecture  dependency-injection  singleton  react 

アプリを入手できる各ビジネス市場（国や州）ごとに要件がわずかに異なるアプリを開発しています。それは一般的な状況のようですが、このシナリオのコード/モジュールの構造化に関する良い記事を見つけることができないようです。 これはC＃アプリであり、戦略パターンとテンプレートパターンの間で議論していますが、フォルダー構造と命名規則の考慮事項もあります。各州の個別のプロジェクトはすぐに管理できなくなるようです（たとえば、5つのコアサービスX 50州のカスタムプロジェクト）= 250プロジェクト!!）おそらく、サービスごとに1つのカスタムプロジェクトが、州ごとにサブフォルダーに編成された専門化を処理していますか？

8 c#  design-patterns  architecture  architectural-patterns 

クリーンアーキテクチャのほとんどの例（Androidプロジェクトはほとんどですが）では、ユースケース/インタラクタークラス（機能をカプセル化するユニット）が、ここやここのように、基本クラス/インターフェースを共有することが多いことに気付きました。他のものは（hereまたはhereのように）しません。代わりに、インタラクターがいくつかのパラメーターを受け入れることを許可し、その後、いくつかのロジックを実行するために使用されます。 これらのアプローチのいずれかが他よりも優れていますか？たとえば、ユーザー入力を必要とする何かのユースケースをパラメーターなしのアプローチがどのように処理するかに特に興味があります。たとえば、ユーザーにエンティティを編集させてサーバーに渡したいとします。同じエンティティをユースケースとそれを呼び出す人に注入することもできますが、その場合は変更可能である必要があるため、変更は両方の場所に反映されます。ただし、不必要なモデルを作成することはできません（スレッド化の問題などのため）。そのような場合の対処方法は？ ユースケース/インタラクターという用語を誤って使用した場合はご容赦ください。ただし、これはAndroidランドでの使用方法であり、確かにデザインパターンで少し遅れている可能性があります。

8 java  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 

C ++で物理シミュレーションプログラムを書いています。私はOOPとC ++の初心者です。 私のプログラムでは、入力ファイルのデータに基づいていくつかのオブジェクトを初期化する必要があります。 たとえば、架空の入力ファイル： # Wind turbine input file: number_of_blades = 2 hub_height = 120 # Airfoil data: airfoil1 = { chord = 2, shape = naca0012} airfoil2 = { chord = 3, shape = naca0016} この例では、TurbineクラスとAirfoilクラスがあるとします。翼オブジェクトは翼弦と形状を知る必要があり、タービンオブジェクトは翼の高さと数を知る必要があります。 各オブジェクトが入力ファイルから自分自身を構築できるように、これを行う必要がありますか？ 例えば： class Turbine { public: Turbine(File input_file); // reads input file …

8 design  object-oriented  c++  architecture  single-responsibility 

この質問は、私を混乱させる私の申請の規則を適用することについてです。 コントローラはサービスを使用しており、サービスはリポジトリを使用しています。 public class CommentController: ApiController{ [HttpPost] public bool EditComment(Comment comment){ commentService.Update(comment); } } public class CommentService{ ICommentRepository repository; .... .... public void Update(Comment comment){ repository.Update(comment); } } ユーザーが認証されると、コメントを更新できます。 ただし、ユーザーは自分のコメントを編集する必要があります。 ただし、管理者はすべてのコメントを編集できます。 ただし、指定した日付以降はコメントを編集できません。 部門で編集 そして、私はこれらのルールのようなものを持っています。 サービスレイヤーで「ユーザー編集独自のコメント」ルールを適用すると、Update methotを変更し、コントローラーのパラメーターUser.Identity.Nameを渡します。 public class CommentService{ ICommentRepository repository; .... .... public void Update(string updatedByThisUser, Comment comment){ // …

8 architecture  asp.net-mvc  architectural-patterns 

マイクロソフトがユニバーサルWindowsプラットフォーム（UWP）向けに導入した機能の1つ、つまりアプリサービスに従っています。これで、アプリはバックグラウンドタスクの形式でサービスを提供できるようになり、他のアプリから呼び出されてタスクを実行できるようになりました。これは、デバイス上のWebサービスのようなものです。 開発者が、自分自身または他の開発者からのサービスを他のアプリに提供することを目的としたアプリサービスを提供するアプリケーションを作成するとします。アプリが常にシステムに存在することを保証する方法がないため、開発者がアプリサービスを使用する必要がある場合、開発者は何ができますか？ すべてのアプリにサービス機能を実装すると、目的が達成されず、他のアプリがインストールされていない場合に機能しないアプリを構築することは悪い決断のように思えます。それでは、アプリサービスは管理されたエンタープライズ環境のみを対象としており、一般の人々を対象としていませんか？

8 design  architecture  windows-10 

リポジトリパターンを使用するMVCサイトがあります。MVCスタイルを十分に使用しているようには思えないので、その一部を再構築する準備をしています。しかし、私もそれを実行したいので、フロントエンドが変更された場合は、交換しやすくなります。 これが私が現在持っているものです モデル-一部のモデルには、エンティティ/クラスが直接含まれています。（ログインモデルにはCustomerクラスが含まれます。これは、Customerテーブル/リポジトリクラスと直接相関しています）ビュー-ビューの一部にリポジトリクエリが含まれています-つまり _customerRepo.Query().FirstOrDefault(c => c.Login == User.Identity.Name); コントローラー-ここではそれほど大きな問題ではありません。コントローラーはいくつかのレポクエリを呼び出します。一部のコントローラーはいくつかのサービスを使用してレポを呼び出します-すなわち _customerService.GetAllCustomers() 呼び出す _customerRepo.Query().All(); これが私の考えです。 1）モデルには、ビューに表示する必要があるデータのみを含める必要があります。Customerテーブル/オブジェクトのすべてのプロパティがビューに表示されている場合でも、ビューがデータベースアーキテクチャまたはバックエンドオブジェクトについて何も認識しないように、それらを独自のモデル/クラスに書き直す必要があります。 2）ビューはモデルオブジェクトにのみアクセスする必要があります 3）（そして、これは私がとるべき道に苦労しているところです） a）コントローラー（またはMVC側のどこか）は、repo / servicesから返されたオブジェクトデータを変換してモデルに変換するコードである必要があります。このコードをモデルコンストラクターに配置できると想定していますが、検証エラーがある場合に備えて、DIはデフォルトの空のコンストラクターを想定していることに気付きました b）コントローラは、データを取得するための適切な名前の付いたメソッド（つまり、_customerRepo.GetAllCustomers（））でrepoインターフェースを呼び出します c）コントローラはサービス層にのみアクセスします。サービスレイヤーは、リポジトリレイヤーとやり取りする唯一のものです。 モデル、コントローラー、サービス、リポジトリのレイヤーを抽出しすぎていますか？サービスレイヤーはすべてリポジトリで実行できるため、オーバーヘッドが多すぎませんか？ オブジェクト/ビジネスエンティティをモデルに変換するための推奨アプローチは何ですか？

8 design-patterns  architecture  asp.net-mvc  architectural-patterns 

3〜4つの相互依存プログラムを開発しています。それらをfoo bar bazとauthと呼びます。お互いに独立してほしいです。各プログラムを他社にライセンス供与する場合を想像してみてください。fooとbarが必要な企業もあれば、bazだけが必要な企業もあります。authを独立しておくことも良い方法のようです。 コンテキスト：authはすべてのシステムの認証を処理します。authのメインのusersテーブルには、user_id、email、password、first、lastがあります fooには、アプリケーションの特定のフィールド（user_id、role_idなど）を持つusersテーブルもあります。 各システムには独自のデータベースがあります。過去に、各アプリケーションから認証データベースへの外部キーを作成しました。他のデータベースから更新権限を削除しましたが、特定の関連フィールドへの選択アクセスを許可しました。これは緊密な依存関係を作成するため、悪い解決策のように見えますが、ユーザー名と電子メールをfoo、bar、またはbazデータベースに格納する必要がないように、dbを正規化することができました。 すべてのデータベースに情報を保存する方が良いでしょうか？または、認証IDをfoo barとbazに保存し、apiを使用してauthIdを使用してユーザー情報を取得する方が良いでしょうか？ 同様に、3つのシステムすべてに顧客がいる可能性があります。確かに、auth dbに依存関係を作成するのは悪いようですが、3つすべての顧客のdbについてはどうですか？ または、1つの中央データベースを作成するのに最適なソリューションです。1つのユーザーテーブル。 他の提案？

8 architecture  web-development  dependencies  normalization 

いくつかの関連ドメインをカバーする主要なアプリケーションREST APIでは、リソースが属するビジネスドメインに基づいてリソースを「エリア」に分割する方が理にかなっていますか、それとも単一のモデルを維持する方が良いですか？ たとえば、「販売」と「在庫」のサブドメインがあります。システムのユーザーは通常、一度に1つのドメインのみを考慮しますが、例外が発生する可能性もあります。両方のドメインに存在する「アイテム」の概念があるため、「アイテム」リソースを2つの異なる方法で実装できます。 各ドメインの概念を表すさまざまなリソースがあり、各リソースは関連データのみを保持しています。 / sales / items /：id / inventory / items /：id すべてのコンテキストで使用されるすべてのデータを含む単一のリソースがあります。 / items /：id ドメインの1つだけに属するリソースもたくさんあります。 「地域」の長所 単一ドメインのみに関心があるユーザー向けのAPIを理解しやすくする リソースの実装が簡単（一度に読み取る/更新する項目が少ない） 特定のドメインごとにリソースをより特殊化/最適化できます より詳細なレベルでリソースへのアクセスを制御する機能 単一の統合モデルの長所 複数のドメインに属するコンセプトの重複リソースはありません ユーザーが複数のドメインで作業する必要がある場合は、すべてのニーズに対応する単一のAPIを使用するだけで済みます 上記のAPIパーティショニングは、APIコントラクトと実装の両方の複雑さを軽減する有効な方法ですか？私はそれがどこにも言及されているのを見たことがありません。 どちらかのアプローチを支持して決定を下すために検討する必要があるものは他にありますか？

8 architecture  rest  api-design 

私の質問は、REST APIを集約またはグループ化するベストプラクティスについてです。多くの異なるベンダー、データソースなどがあるシナリオがあり、REST APIをグループ化することは、システムを保守可能に保つために非常に意味があると思います。 他のシステムで同じエンティティを作成するために、他の多くの（類似した）API呼び出しをトリガーする単一のAPI呼び出しがある多くのシナリオがあります。たとえば、エンティティ "user"の例： フロントエンドがREST APIを呼び出す：PUT ... / user 私が想定しているのは、上記のAPIをリッスンするコードが複数のREST PUT呼び出しを行って、ベンダーA /ユーザー、ベンダーB /ユーザー、ベンダーC /ユーザー、内部システムA /ユーザー、内部システムB /ユーザーなどを呼び出すことです。 このような： +-------------------+ +--------+ PUT +-----------+ CALL | Vendor A API | | | +-------> | user +--------> | | | | | +-----------+ +-------------------+ | | | | Front | PUT +--------++ PUT …

8 architecture  rest  api