レッスン

1.1 アプリケーションのアーキテクチャ このコースは、本格的なアプリケーションのアーキテクチャを長期間設計するわけではないため、初心者向けに設計されています。ただし、心配しないでください。優れたアーキテクチャは原則ではなく例外です。アプリケーションを構築する前に、適切なアプリケーション アーキテクチャを選択することは非常に困難です。 大規模サーバー アプリケーションの一般的なアーキテクチャの例: 階層化アーキテクチャ (階層化アーキテクチャ)。 階層型アーキテクチャ。 サー

3 層アーキテクチャの概要 3 層アーキテクチャは、インターネット上で最も一般的な対話アーキテクチャです。これは、2 層のサーバー部分が 2 つの部分 (ロジック層とデータ層)に分割されたときに現れました。 次のような感じでした。 クライアント層は、ユーザー対話を担当する「分散アプリケーション」の一部です。この層にはビジネス ロジックを含めることはできず、重要なデータを保存することもできません。また、データベース層と直接対話するのではなく、ビジネス ロジック層を介してのみ対話

MVC アーキテクチャの概要 すべてのプログラマが知っている最も一般的なアプリケーション アーキテクチャはMVCです。MVC はModel-View-Controllerの略です。 これはアプリケーションのアーキテクチャというよりは、アプリケーション コンポーネントのアーキテクチャですが、このニュアンスについては後ほど説明します。MVCとは何ですか? MVC は、アプリケーション データと制御ロジックを 3 つの個別のコンポーネント(モデル、ビュー、コントローラー) に分離し

効率 経験豊富なプログラマは、良いアーキテクチャと悪いアーキテクチャを簡単に見分けることができますが、それをいくつかの言葉で説明するように求められると、うまく説明できる可能性は低いでしょう。優れたアーキテクチャに対する単一の基準や単一の定義はありません。 しかし、よく考えてみると、優れたアーキテクチャが満たすべき基準をいくつか書くことができます。優れたアーキテクチャとは、まず第一に、プログラムの開発と保守のプロセスをよりシンプルかつ効率的にする論理アーキテクチャです。 プログ

悪いデザインの基準 人生は非常にシンプルに機能します。多くの場合、賢くなるためには、愚かなことをしないだけで十分です。これはソフトウェア開発にも当てはまります。ほとんどの場合、何かをうまくやるには、下手にやらないだけで十分です。 ほとんどのプログラマーは、システムの設計が不適切だった部分を経験したことがあります。しかし、さらに悲しいことに、皆さんのほとんどは、自分がそのようなシステムの作成者だったことに気づくという悲しい経験をしているでしょう。私たちは最高のものを望んでいまし

6.1 分解 基準はさまざまですが、大規模システムの開発における主なタスクは、システムの複雑さを軽減することです。複雑さを軽減するためには、パーツに分割すること以外はまだ発明されていません。 わかりやすくするために、これを「分割統治」の原則と呼ぶことがありますが、ソフトウェア アーキテクトの観点からは、階層分解について話しています。 複雑なシステムは、少数の単純なサブシステムから構築する必要があります。各サブシステムは、さらに小さな部品から構築され、最小の部品が直接理解して作

階層分解 アプリケーションのクラスの作成をすぐに開始しないでください。まず設計する必要があります。設計は思慮深いアーキテクチャで終わる必要があります。そして、このアーキテクチャを実現するには、システムを一貫して分解する必要があります。 分解は階層的に実行する必要があります。まず、システムは、その動作を最も一般的な形式で記述する大きな機能モジュール/サブシステムに分割されます。次に、結果のモジュールがより詳細に分析され、サブモジュールまたはオブジェクトに分割されます。 オブジェ

8.1 分解がすべて わかりやすくするために、優れた記事「オブジェクト指向システムの分離」からの図で、これから説明する主な点を示しています。 アプリケーション アーキテクチャの設計は簡単だとまだ思っていますか? 8.2 インターフェース、実装の隠蔽 システムの結合を減らすための主な原理は、OOP の原理と、その背後にあるカプセル化 + 抽象化 + ポリモーフィズムの原理です。 それが理由です： モジュールは相互に「ブラック ボックス」である必要があります (カプセル化)。これ

9.1 依存関係の逆転 以前、サーバー アプリケーションでは単にストリームを作成することはできないと述べたことを覚えていますかnew Thread().start()? コンテナのみがスレッドを作成する必要があります。今後はこのアイデアをさらに発展させていきます。 すべてのオブジェクトもコンテナによってのみ作成される必要があります。もちろん、すべてのオブジェクトについて話しているのではなく、いわゆるビジネス オブジェクトについて話しています。ビンとも呼ばれることがよくあります

直接の依存関係をメッセージングに置き換える 場合によっては、モジュールで何らかのイベント/変更が発生したことを他のモジュールに通知する必要があるだけで、この情報が後でどうなるかは問題ではありません。 この場合、モジュールは「お互いのことを知っている」必要はまったくありません。つまり、直接リンクが含まれて直接対話する必要はありませんが、メッセージ (メッセージ) またはイベント (イベント) を交換するだけで十分です。 メッセージングを介したモジュール通信は、直接の依存関係より