「Application Architecture for .NET」を読んだ - 2部

.NETのエンタープライズアプリケーションアーキテクチャ 第2版 (マイクロソフト公式解説書)

.NETのエンタープライズアプリケーションアーキテクチャ 第2版 (マイクロソフト公式解説書)

「Application Architecture for .NET」を読んだ - 1部の続き

第二部アーキテクチャの考察のメモ。

TL;DL

  • Domainを理解することは適切なアーキテクチャの発見に繋がる
  • スムーズで流れるようなプロセスを中心に、ユーザタスクを構造化するのが重要
  • ビジネス層をドメイン空間の現実のプロセスと忠実に一致させるのが重要
    • 正しい事を行う事と、物事を正しく行う事
      • 一方がもう一方から生じるのではなく、どちらも成し遂げる事が重要

5. ドメインアーキテクチャの発見

  • ソフトウェアには現実の世界を正確に映し出すのが期待される
    • ソフトウェアが現実世界のどの部分(Domain)をモデリングしているのか理解する
DDDの本当の付加価値
  • DDDの目的は「ソフトウェアの核心にある複雑さに立ち向かう」
    • 付加価値は、ビジネスcontextの境界を定義するために分析部分を使用することにある
  • 境界付けられたcontext
    • Domainの様々な領域の内、独自のユビキタス言語を持つため別個に扱った方が効果的な領域
ユビキタス言語
  • 言葉の壁は業務の妨げにならないかもしれないが、進行を遅らせる
    • 専門用語をcontextに合わせて調整する
  • ユビキタス言語の目的は全ての関係者が全てのレベルで使用する共通用語を定義すること
    • ビジネスcontextから開発contextに翻訳する必要が無くなり、明確さが促進され仮定しなければならないことが最小限に抑えられる
    • ユビキタス言語はプロジェクトの公式言語
境界付けられたcontext
  • 独自のユビキタス言語とアーキテクチャを必要とするアプリケーション領域
    • 問題空間のサブDomainがソリューション空間の境界付けられたcontextにマッピングされる
    • 境界付けられたcontextの境界内では、ユビキタス言語は1つ
      • Domainは解決する問題
      • DomainModelは問題へのソリューションを実装するmodel
      • サブDomeinはDomainの一部
      • 境界付けられたcontextはソリューションの一部
  • 関係パターン
    • 上流context(u): 下流に影響を与える、下流を強制的に変更する場合もある
    • 下流context(d): 受動的、上流contextによって変更される
階層化アーキテクチャ
  • Presentation層
    • タスクを実行するユーザーインターフェースを提供(画面の集まり)
    • Presentation層に追加されるViewModel == 画面から送信されバックエンドアクションを開始するApplication層の入力Model
  • Application層
    • Presentationの指示に従いビジネスアクションを手配する追加のレイヤー(ユースケースの実装を取り纏める場所)
    • アプリケーションの実装に対する責任を負う。タスクを取り纏め、下位レイヤーに処理を委譲する
    • ビジネスルールを一切認識せず、ビジネス関連の状態情報を保持しない
    • アプリケーションサービス: ビジネスユースケースを指揮するサービス(Domain層の上に配置)
  • Domain層
    • ビジネスロジック全体をホストするレイヤー、ユビキタス言語を実装するレイヤー
    • Domainモデル: Entityモデル(オブジェクトモデル、データと振る舞いを持つ)
    • Domainサービス: 論理的に関連のある振る舞いの集合
  • Infrastructure層
    • 永続化レイヤー、データアクセス層、具体的なテクノロジの使用に関するあらゆるもの

6. プレゼンテーション層

  • 最初にプレゼンテーションに取り組めば、処理すべき注文やそれらの処理方法を素早く効果的に理解するのに役立つ
ユーザーエクスペリエンスファースト
  • データではなくやり取りに焦点を当てるべき(UIとUXの違い)
    • タスクベースの設計 => CQRS
  • UIをUXに置き換える
    • UXはUI以上のもの
    • ユーザが操作しているのを見るまで、提案したUXの良し悪しを正確に判断することは出来ない
シナリオ
  • controllerはApplication層やBusiness層の一部と見なすのではなく、出来るだけ薄く保つようすべき
  • ApplicationService: ワーカーサービス(controllerとマッチする)
    • ユースケースと1対1に対応するメソッドが含まれていて、必要なワークフローを指揮する
    • 入力モデルからViewモデルを返す
  • Webサービスのデバイスサポート
    • 機能検出による分岐(localStorageを対応していたらHTML5扱いみたいな)
    • クライアント側でのデバイス検出によるレスポンシブの実現
  • SPA
    • ユーザアクションに続くタスクのオーケストレーションをクライアント側で行う
      • バックエンドへの複数リクエストを纏めるロジックがクライアント側に含まれる
      • => Webサーバーはデータを交換するための単なるファサードになる

7, 伝説のビジネス層

  • 従来のデータ中心の3層構造から、モデル中心のマルチレイヤーアーキテクチャーへ、イベント駆動型のアーキテクチャーへ
  • Transaction Script Pattern
  • Domain Model Pattern
    • 期待される振る舞いと、動作させるデータの流れに焦点を合わせるアーキテクチャー(クラスという概念から再現する)
    • Domainについて知れば知るほどそれをソフトウェアで模倣しやすくなる
      • エンティティのプロパティよりもアクションに目を光らせる => 振る舞いを突き止めるのに役立つ(Tell Don't Ask)
    • ADM(Anemic Domain Model)(アンチ) Pattern
      • エンティティに含まれているのはプロパティだけで振る舞いがない
データからタスクへの焦点の移動
  • Domain内でのタスクオーケストレーション
    • ビジネスロジックにはタスク、ドメインロジック、その他(ドメインサービス)のオーケストレーションが含まれている
      • ドメインサービスは、エンティティに収まらないロジック、複数のエンティティに関連する操作が含まれているなど
      • ドメインサービスとして定義される操作はステートレス
        • 何らかのデータを渡し、何らかのレスポンスを受け取る。状態は一切管理されない
          境界を跨いだデータの移動
  • ドメインモデルに存在しないデータの集まりをユーザインターフェースに持ち込みたいかもしれない etc => DTOを使う
    • DTOは振る舞いを持たない単純なコンテナ
Mapper.CreateMap<Source, DTO>
var dto = Mapper.Map<DTO>(sourceObj)