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

私は多くの異なる言語で多くのソフトウェアを書きました。また、VerilogとVHDLを使用してFPGAで使用するハードウェアを「書きました」。 私はソフトウェアよりもハードウェアを書くことを楽しむ傾向があり、主な理由の1つは、「完了」して変更する必要のないハードウェアを書くことができるからだと思います。インターフェイスと機能を定義し、テストベンチを書く、ハードウェアモジュールを実装してから、シミュレータを使用してそれをテストします。次に、そのハードウェアモジュールをビルディングブロックとして使用して、より大きくより良いものを作成できます。そのモジュールに機能を追加する必要がある場合は、2番目のモジュールを作成し、そこに機能を追加します。元のモジュールは問題なく機能し、引き続き有用であるため、元のモジュールを捨てることはありません。 ソフトウェアに関する私の主な不満の1つは、「完了」しないことです。追加する別の機能が常にあります。多くの場合、機能を追加すると、以前は正常に機能していた別の場所にバグが発生します。これは、インターフェイスに違反していない限り、ハードウェアでは発生しません。 明確にするために、機能のリストを使用して何かの1つのバージョンを構築することを支持していません。それは永遠です。左側のコードを突いて右側のバグを見つけたくないのですが、これは新しい機能を追加した後に起こるようです。 ハードウェアが「書き込まれる」のと同様の方法でソフトウェアを書くことは可能ですか？既存のコードを書き直したり新しいバグを導入したりすることなく、常に前進を続け、新しい機能を追加できる優れたソフトウェア開発方法論はありますか？

23 architecture  testing  development-methodologies 

LMAXのチームは、1ミリ秒未満のレイテンシで100k TPSを実行する方法についてプレゼンテーションを行いました。彼らは、ブログ、テクニカルペーパー（PDF）、およびソースコード自体を使用して、そのプレゼンテーションをバックアップしています。 最近、Martin Fowler氏は、公開LMAXアーキテクチャ上の優れた論文を、チームがパフォーマンスに大きさの別の注文を上がるために取ったステップのいくつかを、彼らは今、毎秒600万件の注文を処理することができることを言及し、ハイライト。 これまで、ビジネスロジックプロセッサの速度の鍵は、すべてをメモリ内で順番に実行することであると説明してきました。これを実行するだけで（本当に愚かではありません）、開発者は10K TPSを処理できるコードを作成できます。 その後、優れたコードの単純な要素に集中することで、これを100K TPSの範囲に引き上げることができることがわかりました。これには、適切にコード化されたコードと小さなメソッドが必要です-基本的に、これによりHotspotは最適化のより良い仕事をすることができ、実行中のコードをより効率的にキャッシュすることができます。 もう1桁上るには、もう少し賢くなりました。LMAXチームがそこにたどり着くのに役立つとわかったことがいくつかあります。1つは、キャッシュに対応し、ゴミに注意するように設計されたJavaコレクションのカスタム実装を記述することでした。 その最高レベルのパフォーマンスに到達する別の手法は、パフォーマンステストに注意を払うことです。私は長い間、人々がパフォーマンスを改善するためのテクニックについて多くのことを話していることに気づきましたが、実際に違いを生むのはそれをテストすることです ファウラーは、発見されたいくつかの事柄があると述べましたが、彼はいくつかだけに言及しました。 このようなレベルのパフォーマンスを達成するのに役立つ他のアーキテクチャ、ライブラリ、テクニック、または「もの」はありますか？

23 java  architecture  performance 

私は依存関係管理にMavenを使用しているSpring-MVCアプリケーションに取り組んでいます。プロジェクトが大きいので、プロジェクトをいくつかの部分に分割することを考えています。いくつか疑問がありましたが、ここで答えが得られることを願っています。 現在、ROOT.warサーバー上のApache Tomcatのように単一のWARファイルをデプロイしています。プロジェクトが大きいので、通知とメール、サードパーティサービス、PUSH（Cometd）、REST APIなどのようなwebappの部分があります。現在、それらはすべてクラブであり、互いに依存しています。たとえば、通知はユーザーに合わせて調整されるため、Notificationオブジェクトもオブジェクトに依存しPersonます。 大きなプロジェクトを分割する主な目的は、バグ修正、機能の追加、テストなどのために個々のモジュールで作業できるようにすることです。そして、満足したら、このモジュールのみをアプリケーション全体ではなくサーバー上で置き換えることができます。これは可能ですか？ 前述したように、オブジェクト間に依存関係とマッピングがあります。これらは異なるサブモジュール間でどのように管理されますか、またはインポートステートメントだけが他のプロジェクトを含むように変更されますか？ 私が言ったように、意図は個々のモジュールに取り組み、それらを展開できるようにすることです（できればホット）。現在、として単一のWARファイルのみがありますROOT.war。分割により複数のwarファイルが作成され、URLで参照されますdomain-name.com/module_name/some_mappingか？ 現在ドキュメントを確認していますが、これはMavenが提供するマルチモジュールで達成したい主な目的であり、これが実現可能かどうかを知りたいと思っています。さらに情報が必要な場合は、お知らせください。 現在、私は次のように春から親POMを使用しています： <parent> <groupId>io.spring.platform</groupId> <artifactId>platform-bom</artifactId> <version>1.1.3.RELEASE</version> <relativePath /> </parent>

23 java  design  architecture  web-development  maven 

ボブ・マーティンおじさんのビデオ「きれいな建築の原則」のビデオのコンセプトが本当に気に入りました。しかし、このパターンは、その中心にある抽象ファクトリーパターンとビルダーパターンの組み合わせのようなものだと思います。 これは優れたプログラムを作成する1つの方法ですが、唯一の方法ではありません。 Railsとreactjsは、この種のクリーンなアーキテクチャを促進しない2つのフレームワークです。Railsは、ビジネスロジックがモデル（FatModelsおよびSkinnyControllers）内にあることを期待し、コンポーネント内で反応します。どちらのアプローチも、ビジネスロジックとフレームワークコードを密接に結合します。 私は3つの方法のいずれにおいても間違ったことを見つけません。いずれかを選択するのは判断の呼び出しです。 しかし、ビデオでは、クリーンなアーキテクチャにはビジネスロジックとフレームワークの明確な境界があるべきだと彼は示唆しています。フレームワークは、（ウェブ、アンドロイドなど）プラグインする必要があることをプラグインにでビジネスロジックへ。彼はビデオのレールをわずかにモックしています。 それでは、Bob Martinによる「クリーンアーキテクチャ」はすべてのアーキテクチャの経験則ですか、それともオプションの1つにすぎませんか。

22 architecture 

静的言語（C＃やJavaなど）と動的言語（RubyやPythonなど）で構築されるアプリケーションを設計するときに、アーキテクチャ上の大きな違いはありますか？ 一方のタイプに適した設計で、もう一方のタイプに悪い設計の可能性はどれですか？一方のタイプでは実現できない便利な機能がありますが、他のタイプでは実現できません（もちろん、設計とアーキテクチャにおいて）。 また、ダイナミック固有のデザインパターンはありますか？

22 design  architecture  dynamic-typing  static-typing 

クラスを独自のアセンブリ/ DLLに含めるタイミングを決定するためのガイドラインはありますか？私はしばしば二つの考え方を目にします： 1）クラスのすべての「グループ化」は、リポジトリ、サービス、DTO、インフラストラクチャなどの独自のDLLに属します。 2）すべてが単一のDLLにある必要がありますが、名前空間/フォルダーを介して分離する必要があります。たとえば、Core.Repositories、Core.Services、Core.DTOなどの追加の名前空間を持つ「Core」DLLが必要です。 仕事では、すべてを「ビジネス」と呼ばれる単一のアセンブリにまとめます。いくつかのフォルダーがありますが、本当の分離はありません。ビジネスオブジェクト（ロジックを含む、その一部はクラスであってはならない）は、「BusinessObjects」フォルダーに注意せずにまとめられます。複数のクラスで使用されるものは、「コア」フォルダーにあります。ユーティリティは「ユーティリティ」フォルダにあり、データアクセスインフラストラクチャは「データ」フォルダです。 私が取り組んでいる新しいモジュールの場合、個別のデータアクセスレイヤーが必要です（基本的なリポジトリ実装を考えてください）が、他の160（！）そこのクラス。同時に、誰もが単一のライブラリにクラスを詰め込むことに慣れているため、新しいクラスライブラリの作成について心配しています。ただし、フォルダ/ネームスペースは機能します。

22 c#  architecture  directory-structure 

アルゴリズムはコンピューターアーキテクチャに依存しないことをどこかで読みました（どの本かを忘れました）。アルゴリズム自体が計算であると言う人もいます（マシン？）？ 一方、並列プログラミングに関する本には、並列アルゴリズムに関する章があります。並列アルゴリズムは並列アーキテクチャに依存しているように見えますか？ 大きな写真が恋しいですか？ありがとう。

22 algorithms  architecture  parallel-programming 

「標準」のビジネスWebサイトを作成しようとしています。「標準」とは、このサイトが通常のHTML5、CSS、およびフロントエンド、バックエンド（ものを処理するため）用のJavaScriptを実行し、データベース用にMySQLを実行することを意味します。これは基本的なCRUDサイトです。フロントエンドは、データベースに保存されているものを何でも作成します。バックエンドは、ユーザーが入力したものをデータベースに書き込み、処理を行います。ほとんどのサイトと同じように。 コーディングを開始するためにGithubリポジトリを作成する際、フロントエンドバックエンドとAPIの違いを理解していないことに気付きました。私の質問を言い換える別の方法は次のとおりです。APIはこの図のどこに来ますか？ 私はいくつかの詳細と私が持っている質問をリストします-これがあなたに私の実際の質問が何であるかをよりよく理解してくれることを願っています。私は尋ねる特定の質問を知らないので混乱しています いくつかの詳細： Model-View-Controllerパターンを試してみたい。これにより質問/回答が変更されるかどうかはわかりません。 APIはRESTfulになります 私は私の希望私自身のAPIを使用するバックエンドをカンニングして、特別なクエリを呼び出すためにバックエンドを可能するのではなく。このスタイルはより一貫していると思います。 私の質問： フロントエンドは、APIを呼び出すバックエンドを呼び出しますか？または、フロントエンドはバックエンドを呼び出すのではなく、APIを呼び出すだけですか？ バックエンドはAPIを実行するだけで、APIはバックエンド（バックエンドが究極のコントローラーとして機能し、タスクを委任する）に制御を返しますか？ フロントエンドバックエンドとともにAPIの役割を説明する長く詳細な回答が推奨されます。答えがプログラミングのモデル（Model-View-Controllerパターン以外のモデル）に依存する場合、APIのこれらの他の考え方を説明してください。ありがとう。私はとても混乱しています。

22 design  web-development  architecture  terminology 

私のプロジェクトの1つで使用するためのPiranha（http://piranhacms.org/）と呼ばれるオープンソースCMSを評価しています。少なくとも私にとっては、次のコードが興味深く、少し混乱していることがわかりました。クラスが同じ型のベースから継承している理由を理解するのに役立つことがありますか？ public abstract class BasePage<T> : Page<T> where T : BasePage<T> { /// <summary> /// Gets/sets the page heading. /// </summary> [Region(SortOrder = 0)] public Regions.PageHeading Heading { get; set; } } クラスBasePage<T>が定義されている場合、なぜ継承するのPage<T> where T: BasePage<T>ですか？どのような特定の目的に役立ちますか？

21 c#  architecture  .net  cms 

以下の例は完全に人為的であり、その唯一の目的は私のポイントを理解することです。 SQLテーブルがあるとします： CREATE TABLE rectangles ( width int, height int ); ドメインクラス： public class Rectangle { private int width; private int height; /* My business logic */ public int area() { return width * height; } } ここで、データベース内のすべての長方形の合計面積をユーザーに表示する必要があると仮定します。テーブルのすべての行をフェッチし、それらをオブジェクトに変換して、それらを反復処理することで、それを実現できます。しかし、これはばかげているように見えます。なぜなら、テーブルにはたくさんの長方形があるからです。 だから私はこれをします： SELECT sum(r.width * r.height) FROM rectangles r これは簡単で高速で、データベースの長所を利用します。ただし、ドメインクラスでも同じ計算を行うため、重複したロジックが導入されます。 もちろん、この例では、ロジックの複製は致命的ではありません。ただし、他のドメインクラスでも同じ問題に直面します。これはより複雑です。

21 architecture  maintainability 

アジャイル開発では、ポリシーとアプリケーションロジックは永続化メソッドなどの詳細よりも重要であるため、最後に永続化の決定を下す必要があると誰かが説明してくれました。したがって、この方法の弱点が明らかになるまでフラットファイルなどのより単純な永続性から始めてから、リレーショナルデータベースなどを使用して永続性を変更することをお勧めします。 これは本当ですか、それともコンセプトを誤解しましたか？これはアジャイルチームが通常どのようにアプリケーションを構築するのですか？その理由は何ですか？また、このアプローチを採用すべきではないのはいつですか？

21 architecture  agile  database  persistence 

多くの場合、データアクセスを簡単にモックでき、アクセスするデータを決定するパラメーターを受け入れる署名を提供するため、このような関数を作成していることに気付きます。 public static string GetFormattedRate( Func<string, RateType>> getRate, string rateKey) { var rate = getRate(rateKey); var formattedRate = rate.DollarsPerMonth.ToString("C0"); return formattedRate; } または public static string GetFormattedRate( Func<RateType, string> formatRate, Func<string, RateType>> getRate, string rateKey) { var rate = getRate(rateKey); var formattedRate = formatRate(rate); return formattedRate; } 次に、私はそれを次のように使用します： using FormatterModule; …

20 c#  architecture  functional-programming 

私が知っているすべてのIT担当者ではないにしても、ほとんどの場合、コーディングの前にUMLまたは他のタイプのダイアグラムでソフトウェアをモデル化することが有益であると考えています。（私の質問は、特にUMLに関するものではなく、ソフトウェア設計のグラフィックまたはテキストによる説明です。） 私はそれについてはよくわかりません。主な理由は次のとおりです。コードは嘘をつかない。コンパイラーまたはインタープリターによってチェックされます。自動化されたテストがあり、静的コード分析に合格する必要があります。モジュールが別のモジュールと正しくインターフェイスしていない場合、エラーメッセージが表示されるため、通常はコードで明らかです。 このすべてを図や他のドキュメントで行うことはできません。はい、UMLをチェックするツールはありますが、これまで見てきたことはすべて非常に限られています。したがって、これらのドキュメントは不完全、一貫性のない、または単純な偽である傾向があります。 ダイアグラム自体が一貫していても、コードが実際にそれらを実装していることを確認することはできません。はい、コードジェネレーターはありますが、すべてのコードを生成することはありません。 モデリングの強迫観念は、コードが不可解に不可解な混乱であり、建築家、デザイナー、または全体像をつかむ他の有給の人々が対処する必要がないという前提から生じることに執着するように感じることがあります。そうでなければ、あまりにも高価になってしまいます。したがって、設計上のすべての決定は、コードから移動する必要があります。コード自体は、それを書くことができる（そしておそらく読むことができる）専門家（コードモンキー）に任せるべきですが、他に何も処理する必要はありません。これはおそらくアセンブラが唯一のオプションであったときに意味をなしましたが、最新の言語では非常に高いレベルの抽象化でコーディングできます。したがって、モデリングの必要性は実際にはありません。 ソフトウェアシステムをモデル化するための引数がありません。 ところで、図はソフトウェア設計の特定の側面を文書化して伝達するのに最適な方法であると考えていますが、それはソフトウェア設計をそれらに基づいて行うべきではないということです。 明確化： この質問は不明確であるとして保留されています。したがって、いくつかの説明を追加しましょう。 私は、ソフトウェア設計に関する真実の主要な情報源としてソフトウェアをモデル化する（コードではない）ドキュメントを使用することが理にかなっているかどうかを尋ねています。コードの大部分がこれらのドキュメントから自動的に生成されることを念頭に置いていません。この場合、ドキュメント自体をモデルではなくソースコードと見なします。 この手順の欠点をいくつか挙げたので、（私の経験では）なぜ多くの人がこの手順をソフトウェア設計の好ましい方法と考えているのか疑問に思います。

20 design  architecture  uml  modeling 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 閉じた3年前。 ソフトウェアをコーディングする場合、構築するアプリケーションに関して、アーキテクチャは常にベストプラクティスまたは実践的プラクティスのどちらである必要がありますか？ 5年間存続する可能性のある2ページのWebアプリケーションを構築し、その5年間で2つの機能拡張を行う場合、依存性注入、デザインパターン、ビューモデルを備えたモデルビューコントローラーなどでコーディングする必要があります

20 architecture  coding-standards 

C＃と.NETフレームワークは、Delphiの主任開発者であるAnders Hejlsbergによって設計された、本質的に「Javaのように書き換えられたDelphi」として始まったという歴史に詳しい人にはよく知られています。それ以来、物事はかなり分かれていますが、類似点の初期には非常に明白だったため、。 しかし、私は最近いくつかの.NETのものを見てきましたが、Delphiの最も興味深く有用な機能の1つは完全に欠落しているようです。それに慣れていない人のTClassために、Type型は.NET の型と同様に、クラスへの参照を表します。しかし、.NETがTypeリフレクションに使用する場合、DelphiはTClass言語の非常に重要な組み込み部分として使用します。クラスサブタイプ変数や仮想クラスメソッドなど、それなしでは存在しない、存在できないさまざまな便利なイディオムが可能になります。 すべてのOO言語には仮想メソッドがあり、異なるクラスがメソッドの同じ基本概念を異なる方法で実装し、その後、呼び出されたオブジェクトインスタンスの実際のタイプに基づいて実行時に適切なメソッドが呼び出されます。Delphiは、この概念をクラスに拡張します。特定のクラスサブタイプとして定義されたTClass参照がある場合（つまりclass of TMyClass、変数が継承する任意のクラス参照を受け入れることができますがTMyClass、階層スコープの外部ではない）それは、クラスの実際の型を使用して、インスタンスなしで呼び出すことができます。たとえば、このパターンをコンストラクターに適用すると、Factory実装が簡単になります。 .NETには同等のものはないようです。クラス参照（特に仮想コンストラクタや他の仮想クラスメソッド！）と同じくらい便利なのに、なぜそれらが取り残されたのかについて何か言いましたか？ 具体例 フォームの逆シリアル化 Delphi VCLはDFM、コンポーネント階層を記述するためのDSL である形式でフォームを保存します。フォームリーダーがDFMデータを解析すると、次のように記述されているオブジェクト間で実行されます。 object Name: ClassName property = value property = value ... object SubObjectName: ClassName ... end end ここで興味深いのはそのClassName部分です。各コンポーネントクラスは、その時点でTClassコンポーネントストリーミングシステムに登録しinitializationます（静的コンストラクターは、わずかに異なるだけで、起動時に直ちに発生することが保証されています）。これにより、クラス名をキーとしてstring-> TClassハッシュマップに各クラスが登録されます。 各コンポーネントはから派生しTComponent、単一の引数をとる仮想コンストラクタを持ちますOwner: TComponent。どのコンポーネントもこのコンストラクタをオーバーライドして、独自の初期化を提供できます。DFMリーダーはクラス名を読み取ると、前述のハッシュマップで名前を検索し、対応するクラス参照を取得し（または、存在しない場合は例外を発生させます）、仮想TComponentコンストラクターを呼び出します。これは、登録関数がTComponentから派生するために必要なクラス参照を取得し、適切なタイプのオブジェクトが作成されるためです。 これがないと、WinFormsの同等物は...まあ...それを率直に言って大きな混乱であり、新しい.NET言語が独自のフォーム（デ）シリアル化を完全に再実装する必要があります。考えてみると、これは少し衝撃的です。CLRを持つことの全体的な目的は、複数の言語で同じ基本インフラストラクチャを使用できるようにすることなので、DFMスタイルのシステムは完全に理にかなっているでしょう。 拡張性 私が書いたイメージマネージャークラスには、データソース（イメージファイルへのパスなど）を提供し、コレクションにはないがデータソースでは使用可能な名前を取得しようとすると、新しいイメージオブジェクトを自動的に読み込みます。class ofベースイメージクラスとして型付けされたクラス変数があり、作成される新しいオブジェクトのクラスを表します。デフォルトが付属していますが、特別な目的で新しい画像を作成する場合、画像をさまざまな方法で設定する必要があるという点がいくつかあります。（アルファチャネルなしで作成する、PNGファイルから特殊なメタデータを取得してスプライトサイズを指定するなど） これは、大量の構成コードを記述し、新しいオブジェクトを作成する可能性のあるすべてのメソッドに特別なオプションを渡すことで実行できます...または、仮想メソッドをオーバーライドするベースイメージクラスのサブクラスを作成することもできます。問題のアスペクトが構成された後、try / finallyブロックを使用して、必要に応じて「デフォルトクラス」プロパティを一時的に置き換え、復元します。クラス参照変数を使用してこれを行うのははるかに簡単であり、代わりにジェネリックを使用して行うことはできません。

20 architecture  .net  history  delphi