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

ソフトウェアシステムの高レベルの設計と説明。アーキテクチャ設計では、実装、アルゴリズム、およびデータ表現の詳細を抽出して、「ブラックボックス」コンポーネントの相互作用に集中します。

3
ASP.NET WebFormsアプリケーションに最適なアーキテクチャ
クライアント用のASP.NET WebFormsポータルを作成しました。プロジェクトは、最初から適切に計画および構造化されているのではなく、ある程度進化しています。その結果、すべてのコードが同じプロジェクト内でレイヤーなしでまとめられます。クライアントは機能に満足しているので、プロジェクトのリリースに自信を持つようにコードをリファクタリングしたいと思います。アーキテクチャの設計にはさまざまな方法があるようですが、最善の方法についていくつかの意見をお願いします。 機能性 ポータルでは、管理者がHTMLテンプレートを構成できます。他の関連する「パートナー」は、IFrameコードをサイトに追加することにより、これらのテンプレートを表示できます。これらのテンプレート内で、顧客は製品を登録および購入できます。APIはWCFを使用して実装されており、外部の企業もシステムとインターフェイスできます。管理者セクションでは、管理者がさまざまな機能を設定し、各パートナーのレポートを表示できます。システムは請求書と電子メール通知を顧客に送信します。 現在のアーキテクチャ 現在、データベースへの読み取り/書き込みにEF4を使用しています。EFオブジェクトは、aspxファイル内で直接使用されます。これにより、サイトを作成している間、迅速な開発が容易になりましたが、dbとUIを密に結合しているため、このように維持することはおそらく受け入れられません。特定のビジネスロジックがEFオブジェクトの部分クラスに追加されました。 質問 リファクタリングの目標は、サイトをスケーラブルで、簡単に保守でき、安全にすることです。 これにはどのようなアーキテクチャが最適ですか?各レイヤーに何があるべきか、DTO / POCO /アクティブレコードパターンを使用する必要があるかどうかなどを説明してください。 DTO / BOを自動生成する強力な方法があるので、追加のレイヤーがあっても、将来の拡張は簡単に実装できますか? プロジェクトをWebFormsからMVCに変換することは有益でしょうか?

9
開発者は、実際のプログラムの前に内部ライブラリをコンパイルする必要がありますか?
最近、私が一緒に仕事をしている上級開発者が、開発者に最新バージョンを入手し、プロジェクトの一部として主要な内部ライブラリをコンパイルするよう要求することを主張しました。これは、プロジェクトチームが内部のMavenリポジトリから取得する安定したバージョンを使用して作業する必要があるという反論とは対照的です。開発者は、ソースコードを開発者のマシンで利用できるようにすると、ライブラリのソースを読み取ることができるので時間を節約できると主張しました。必要な機能が利用可能かどうかを判断するコード。 上級開発者には有効な議論がありますか?それとも、開発者に、ライブラリのソースコードを読み取って、カプセル化の基本的な哲学に対抗し、そもそもライブラリを用意するように要求するのでしょうか。

4
LINQとデータアクセスレイヤー
私は常に、自分のビジネスロジックとUIコードとは完全に別の「レイヤー」でデータアクセスコードを処理することを学びました。これは常に私にとって非常に優れたアーキテクチャであり、私が目にするすべての「ルール」またはベストプラクティスは、このスタイルのコーディング、特に単一責任の原則にうまく適合しています。 ほとんどのホームプロジェクトでは、私が作成した独自のORMを使用します。これは、常にオープンソースを作成することを目的としていました。しかし、それ以来、LINQが利用可能になりました。これは、私のORMが機能する方法と非常によく似ていました(しかし、より優れています)。 以前に自分のORMを使用して、今はLINQを使用して実行できないことはありません(REST統合のビットを除く)。だから私の質問です。LINQは新しいデータアクセスレイヤーですか?このレイヤーはもう必要ですか?私のBLLはLINQと直接通信する必要がありますか?それとも、この悪い習慣はまだですか? 編集: 元の質問はLINQ to Entitiesに関するものでしたが、LINQ to SQLに関しては興味深い答えがたくさんあります。両方の人々の考えは何ですか?LINQ to SQLでDALを実際に置き換えることはできませんが、Entity Frameworkは収集できますか?

1
複数のZendアプリケーションコードの編成
過去1年間、私はすべてZendフレームワークに基づく一連のアプリケーションに取り組んでおり、すべてを使用しなくてもすべてのアプリケーションがアクセスする必要がある複雑なビジネスロジックを中心に(それぞれに複数のライブラリフォルダーを用意するよりも簡単です)それらはすべて共通のセンターでリンクされているため、アプリケーション)。 プロジェクトの詳細については詳しく説明しませんが、コードを "グループ化"する方法について(プロジェクトだけで作業しているので)いくつかの情報を探しています。私は、依存関係をできる限り取り除くような方法ですべてを分割しようとしました。 私はそれを論理的に可能な限り分離したままにしようとしているので、自分の時間がアップする12か月の時間で、他の誰かが私が作成したものを拡張するのに問題はありません。 構造例: applicationStorage\ (contains all applications and associated data) applicationStorage\Applications\ (contains the applications themselves) applicationStorage\Applications\external\ (application grouping folder) (contains all external customer access applications) applicationStorage\Applications\external\site\ (main external customer access application) applicationStorage\Applications\external\site\Modules\ applicationStorage\Applications\external\site\Config\ applicationStorage\Applications\external\site\Layouts\ applicationStorage\Applications\external\site\ZendExtended\ (contains extended Zend classes specific to this application example: ZendExtended_Controller_Action extends zend_controller_Action ) …

3
マルチテナンシーのサポート
シングルテナントアプリをマルチテナントアプリに変換するときに発生する典型的な課題は何ですか?セキュリティとデータの分離が最も重要だと私は思います。他には何がありますか? 私はかなり重要な自動化作業のアーキテクトの1人であり、歴史的にそれは私たちの会社がそれを使用しているだけでした。他の人にも利用してもらいたい。「マルチテナント化」について話すときは常に、あるテナントを持つユーザーを別のテナントが所有するデータから遠ざけることと、あるテナントを持つユーザーが(意図的または意図せずに)別のテナントに影響を与えないようにすることを話し合いますテナントの環境。私が疑問に思っているのは、セキュリティ/データ分離が本当にここでの唯一の主要な懸念であるのか、それとも私たちが考えていない他のいくつかの主要な懸念があるのか​​です。

2
コマンドハンドラーとDDD
クエリサービスを使用してデータを取得し、コマンドサービスを使用してコマンドを送信するASP.NET MVCアプリケーションがあります。私の質問は、コマンド部分についてです。 リクエストが届くと、コマンドサービスはコマンドディスパッチャーを使用して、指定されたコマンドハンドラーにコマンドをルーティングします。このコマンドハンドラーは最初にコマンドを検証し、すべてが許容できる場合はコマンドを実行します。 具体例:AddCommentToArticleCommandHandlerは、ArticleId、CommentText、EmailAddressを持つAddCommentToArticleCommandを受け取ります。 最初; -記事が存在するかどうかを確認します-記事が閉じていないかどうかを確認します-コメントテキストが20〜500文字で入力されているかどうかを確認します-電子メールアドレスが入力されており、有効な形式であるかどうかを確認します この検証をどこに置くか疑問に思っていますか? 1 /コマンドハンドラ自体。ただし、他のコマンドハンドラで再利用することはできません。 2 /ドメインエンティティ内。しかし、ドメインエンティティはリポジトリやサービスを認識していないため、必要な検証を実行できません(記事が存在するかどうかを確認できません)。ただし、一方で、エンティティにロジックが含まれていない場合は、DDDの原則に従っていない単純なデータコンテナーになります。 3 /コマンドハンドラーはバリデーターを使用するため、検証を他のコマンドハンドラーで再利用できます。 4 /その他のメカニズム? この特定の例の一連の責任と、その中で役割を果たすオブジェクト(エンティティ、リポジトリなど)を探しています。 コマンドハンドラーからリポジトリまで、これをどのように実装するかについてのアイデアはありますか?

5
インタビューで「プロジェクトの現在のアーキテクチャを説明してください」という質問にどのように答えますか?[閉まっている]
休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか?質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 4年前休業。 私が現在取り組んでいるアプリケーションは少し巨大です。15分程度では説明できません。 前回、いくつかのクラス図とそれらがどのようにリンクされているかを描くことになりましたが、インタビュアーが答えに満足していないことがわかりました。 この質問に答えるときに強調すべき主なことは何ですか? たとえば、セッションの管理方法、永続性の実現方法はほとんどありません。 他に見逃してはならないものは何ですか?

6
コードベースをどのように計画する必要がありますか?[閉まっている]
休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか?質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 9か月前に閉鎖。 私は現在、5,000行を超えるコードに到達しようとしているプロジェクトに取り組んでいますが、デザインを完全に考えたことはありません。コードを構造化および編成するには、どの方法を使用すればよいですか?紙とペン?UML図?他に何か?
10 architecture  uml 

4
イベントリスナーモデルが必要であるという症状がある「コードのにおい」は何ですか。
イベントリスナーアプローチが必要であることを示すコードベースの症状は何ですか? 他のクラスのデザインタイムセットでは定義されていない、複数で呼び出す必要があるクラスがある場合、何らかのシグナリングフレームワークが必要ですが、他にどのような状況があるのか​​聞きたいですイベントベースのモデルに変更することで改善されました。

4
ドメイン駆動設計でのリファクタリング[終了]
休業。この質問には詳細または明確さが必要です。現在、回答を受け付けていません。 この質問を改善してみませんか?詳細を追加し、この投稿を編集して問題を明確にしてください。 6年前休業。 私はプロジェクトに取り組み始めたばかりであり、ドメイン駆動設計(Eric Evansが定義するDomain-Driven Design:Tackling Complexity in the Heart of Software)を使用しています。私たちのプロジェクトは確かにこの設計の候補だと思いますエヴァンスが彼の本でそれを説明するパターン。 私は絶えずリファクタリングするという考えに苦労しています。 私は、どのプロジェクトでもリファクタリングが必要であり、ソフトウェアの変更に伴って必然的に起こることを知っています。ただし、私の経験では、リファクタリングは、ドメイン変更の理解としてではなく、開発チームのニーズが変化したときに発生します(Evansが言うように、「より深い洞察へのリファクタリング」)。私は、ドメインモデルの理解におけるブレークスルーに最も関心があります。小さな変更を加えることは理解していますが、モデルに大きな変更が必要な場合はどうなりますか? より明確なドメインモデルを取得した後、リファクタリングする必要がある自分(および他の人)を説得する効果的な方法は何ですか?結局のところ、コードの編成またはパフォーマンスを改善するためのリファクタリングは、ユビキタス言語コードの観点から表現力を高めることとはまったく別のものである可能性があります。時々、リファクタリングするのに十分な時間がないように思えます。 幸いにも、SCRUMはそれをリファクタリングに役立てます。SCRUMの反復的な性質により、小さなピースを作成し、それを変更することが容易になります。しかし、時間の経過とともにそのピースは大きくなり、そのピースが大きくなりすぎて変更が困難になるとしたらどうでしょうか。 ドメイン駆動設計を採用するプロジェクトに取り組んだ人はいますか?もしそうなら、これについていくつかの洞察を得ることは素晴らしいでしょう。DDDを正しく理解するのは非常に難しいため、私は特にいくつかの成功事例を聞きたいと思います。 ありがとう!

2
テスト駆動開発プロセスにおけるソフトウェアアーキテクトの役割は何ですか?
私が理解しているように、テスト駆動開発はプログラムの仕様を定義するためのテストを書くことです(私が間違っていれば修正できます)。 ソフトウェアの仕様(パブリックAPIを含む)を作成する責任者がいる場合(彼をソフトウェアアーキテクトと呼びましょう)、それはソフトウェアアーキテクトがすべてのテストを作成する必要があることを意味しますか? または、ソフトウェアアーキテクトが仕様を作成してから、それらを開発者に渡してテストを作成しますか? それとも、すべての開発者が独自のテストを作成できるようにし、ソフトウェアアーキテクトの存在を忘れることによって、仕様が有機的に成長することを許可しますか?
10 architecture  tdd 

2
バックエンドで使用される言語で書かれたフロントエンド![閉まっている]
休業。この質問には詳細または明確さが必要です。現在、回答を受け付けていません。 この質問を改善してみませんか?詳細を追加し、この投稿を編集して問題を明確にしてください。 6年前休業。 私はウェブ開発の経験から、PHP、Java、Pythonなどの言語がバックエンド開発のもの(サーバーで実行されるソフトウェア)に使用され、フロントエンド言語にはJS / HTML / CSSが使用されることを知っています。 しかし、多くの企業が、たとえばフロントエンド開発にPHPを、バックエンドにpythonを使用していると言っているのを目にします。 それは、PHPがREST、RPCなどを介して他の言語で書かれた他のサービスを呼び出すためのフロントエンドであることを意味しますか?

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

4
外部のコマンドラインアプリケーションを呼び出すか、そのアプリケーションのロジックを内部化する方が良いでしょうか?
ワークフローを自動化するために、基本的に既存のツールの束をリンクするだけの「パイプライン」タイプのプロセスがあります。ステップの1つとして、既存のコマンドラインツールがあり、そのステップで実行する必要のある処理をすでに実行しています。 外部CLIツールはJavaベースであり、パイプラインも同様であるため、ツールをパイプラインステップに直接統合することは可能ですが、ツールは非常に複雑で、現在、コマンドライン入力(次のようなもの)と密接に関連しています37の構成フラグオプション)。 問題は、単に外部プロセスを呼び出して呼び出す方が良いのでしょうか、それともアプリケーション内に外部コードを統合する方が良いのでしょうか。 外部プロセスの統合と呼び出しのメリットとデメリットは何ですか?

7
アーキテクチャから開発への移行に関してベストプラクティスはありますか?
アーキテクチャから開発にタスクを引き渡すプロセスの改善を検討しています。 スケールの一端では、各開発者が自分のやり方で物事を行っているため、混乱を招くリスクのあるアーキテクチャガイダンスはありません。 すべてが指定されているスケールの反対側では、仕様よりも開発に時間がかかり、非常に退屈な開発タスクが発生するリスクがあります。 誰かがこれらの両極端の間の最適な中間点を見つけましたか?どの成果物を開発に提供しますか?例:モジュール、クラス構造、またはシーケンス図?

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.