「Application Architecture for .NET」を読んだ - 2部
.NETのエンタープライズアプリケーションアーキテクチャ 第2版 (マイクロソフト公式解説書)
- 作者: Dino Esposito,Andrea Saltarello,日本マイクロソフト(監訳),クイープ
- 出版社/メーカー: 日経BP社
- 発売日: 2015/06/04
- メディア: 単行本
- この商品を含むブログ (2件) を見る
「Application Architecture for .NET」を読んだ - 1部の続き
第二部アーキテクチャの考察のメモ。
TL;DL
- Domainを理解することは適切なアーキテクチャの発見に繋がる
- スムーズで流れるようなプロセスを中心に、ユーザタスクを構造化するのが重要
- ビジネス層をドメイン空間の現実のプロセスと忠実に一致させるのが重要
- 正しい事を行う事と、物事を正しく行う事
- 一方がもう一方から生じるのではなく、どちらも成し遂げる事が重要
- 正しい事を行う事と、物事を正しく行う事
5. ドメインアーキテクチャの発見
- ソフトウェアには現実の世界を正確に映し出すのが期待される
- ソフトウェアが現実世界のどの部分(Domain)をモデリングしているのか理解する
DDDの本当の付加価値
- DDDの目的は「ソフトウェアの核心にある複雑さに立ち向かう」
- 付加価値は、ビジネスcontextの境界を定義するために分析部分を使用することにある
- 境界付けられたcontext
- Domainの様々な領域の内、独自のユビキタス言語を持つため別個に扱った方が効果的な領域
ユビキタス言語
- 言葉の壁は業務の妨げにならないかもしれないが、進行を遅らせる
- 専門用語をcontextに合わせて調整する
- ユビキタス言語の目的は全ての関係者が全てのレベルで使用する共通用語を定義すること
- ビジネスcontextから開発contextに翻訳する必要が無くなり、明確さが促進され仮定しなければならないことが最小限に抑えられる
- ユビキタス言語はプロジェクトの公式言語
境界付けられたcontext
- 独自のユビキタス言語とアーキテクチャを必要とするアプリケーション領域
- 関係パターン
- 上流context(u): 下流に影響を与える、下流を強制的に変更する場合もある
- 下流context(d): 受動的、上流contextによって変更される
階層化アーキテクチャ
- Presentation層
- タスクを実行するユーザーインターフェースを提供(画面の集まり)
- Presentation層に追加される
ViewModel
== 画面から送信されバックエンドアクションを開始するApplication層の入力Model
- Application層
- Domain層
- Infrastructure層
- 永続化レイヤー、データアクセス層、具体的なテクノロジの使用に関するあらゆるもの
6. プレゼンテーション層
- 最初にプレゼンテーションに取り組めば、処理すべき注文やそれらの処理方法を素早く効果的に理解するのに役立つ
ユーザーエクスペリエンスファースト
- データではなくやり取りに焦点を当てるべき(UIとUXの違い)
- タスクベースの設計 => CQRS
- UIをUXに置き換える
- UXはUI以上のもの
- ユーザが操作しているのを見るまで、提案したUXの良し悪しを正確に判断することは出来ない
シナリオ
- controllerはApplication層やBusiness層の一部と見なすのではなく、出来るだけ薄く保つようすべき
- ApplicationService: ワーカーサービス(controllerとマッチする)
- Webサービスのデバイスサポート
- 機能検出による分岐(localStorageを対応していたらHTML5扱いみたいな)
- クライアント側でのデバイス検出によるレスポンシブの実現
- SPA
- ユーザアクションに続くタスクのオーケストレーションをクライアント側で行う
7, 伝説のビジネス層
- 従来のデータ中心の3層構造から、モデル中心のマルチレイヤーアーキテクチャーへ、イベント駆動型のアーキテクチャーへ
- Transaction Script Pattern
- Domain Model Pattern
- 期待される振る舞いと、動作させるデータの流れに焦点を合わせるアーキテクチャー(クラスという概念から再現する)
- Domainについて知れば知るほどそれをソフトウェアで模倣しやすくなる
- エンティティのプロパティよりもアクションに目を光らせる => 振る舞いを突き止めるのに役立つ(Tell Don't Ask)
- ADM(Anemic Domain Model)(アンチ) Pattern
- エンティティに含まれているのはプロパティだけで振る舞いがない
データからタスクへの焦点の移動
- Domain内でのタスクオーケストレーション
- ドメインモデルに存在しないデータの集まりをユーザインターフェースに持ち込みたいかもしれない etc => DTOを使う
- DTOは振る舞いを持たない単純なコンテナ
- エンティティからDTOを作成する
- AutoMapper, Adapter
- DTOは振る舞いを持たない単純なコンテナ
Mapper.CreateMap<Source, DTO> var dto = Mapper.Map<DTO>(sourceObj)