CQRSはトップレベルのアーキテクチャではなく、テクノロジに依存しないアーキテクチャ
- ある程度設計パターンに依存するが、CQRSはパターンそのもの。CQRSはシンプルかつ強力で、一般的なアプリケーションに適している
CQRSはドメイン層を切り離すことと、読み取り/書き込みに別々のモデルを使用することを提唱する
- 最大のポイントは、コマンドをクエリから引き離す
- 読み取り用(1つの中間層がデータを取得する)/書き込み用(1つの中間層がシステム状態を変更するコマンドを処理する)にストレージを用意することになる
Eventは分析と実装に対してタスクベースのアプローチを推進する
- EventSourcingは標準的なOOPモデルやRDBモデルに従ってデータを格納するのではなく、イベントが発生した時にそれらを記憶するだけ
CQRSの真価は一方を最適化することでもう一方が機能しなくなるというリスクを負うことなく、コマンドとクエリのパイプラインを自由に最適化できる点にある
Cutting Edge - 一般的なアプリケーション向けの CQRS
Cutting Edge - CQRS とイベント: 強力なコンビ

10. CQRSの紹介

DDDの当初のビジョンに不可欠なのは、境界付けられたコンテキストに対して推奨されるアーキテクチャです

コマンドとクエリの分離

一般的に言えばソフトウェアシステムで実行されるアクションはクエリかコマンドに分類できる
クエリ: システムの状態をいかなる方法でも変更せず、データを返すだけ(読み取り)
コマンド: システムの状態を変更する。ステータスコードか確認応答を返すとしてもそれ以外のデータは返さない(書き込み)
CQRSではDomain層を1つではなく2つ使用する
- それぞれのDomain層に独自のアーキテクチャとクエリ/コマンドに特化した一連のサービスを割り当てる
- クエリスタックのベースはSQLクエリだけで極限まで単純化されるべき
CQRSの利点
- 設計の単純化
- スケーラビリティ向上の可能性

クエリスタック

読み取りモデルのファサードの設計
- リポジトリに関してはクエリスタックにおいて必要なさそう
- 階層形式の式木(LET) IQueryable interface

コマンドスタック

コマンドスタックの関心はアプリケーションの状態を変更するタスクのパフォーマンスだけ。アプリケーション層は従来通り、プレゼンテーションからリクエストを受け取りそれらを実行する手はずを整える
コマンドとはバックエンドに対して実行されるアクションのこと(単一方向)
ex. タスクを実行したユーザがフィードバックを期待して待つケース
- コマンドとクエリが同じコンテキストに属するのであれば問題はない
- 別々なら、1つは対話形式で利用され、もう1つはプログラムから開始される
入力を処理するためのフロントエンドリクエストはアプリケーション層(受信者)に送信されるメッセージと見なせる
- メッセージはこの後の処理に必要なデータを含んだDTO

public class Message {
    // 必要に応じて一般的なプロパティを定義
    // 但し、クラスはプロパティを持たない単なるマーカーでも構わない
}

メッセージはコマンドとイベントの2種類がある
- コマンドは命令型で明示的なリクエスト
  - 1つのハンドラに送信される
  - システムによって拒否されることがある
  - 効果はシステムの状態に応じて異なることがある
  - コマンドが境界付けられたコンテキストの境界を超えることは無い
- イベントは既に発生していることの通知としての役割を果たすメッセージ
  - イベントを処理するハンドラはいくつ指定しても構わない
  - イベントのサブスライバがそのイベントが発生した境界付けられたコンテキスト内にいるとは限らない
  - 既に発生している何かを表す単純な理由によりImmutableとみなすべき
イベントソーシングは、メッセージを保存することで詳細で包括的な監視ログを形成できること
- システム内で発生したイベントは後から確認出来る、イベントを再現、推定することが可能
コマンドを非同期で実行する必要がある場合は、コマンドではなくイベントとして設計すべき
コマンドとイベントはどちらもMessageの派生クラス
イベントに関しては何かが発生したことを反映した名前にすること
- ex. Is-Gold => CustomerReachedGoldStatusEvent

// Command
public class CheckoutCommand: Message {
    public string CartId { get; private set; }
}

// Event
public class DomainEvent: Message {
    // 一般的なプロパティ
    // イベントが発生した時間を追跡するtimestamp
    // イベントを発生させたuserId
    // イベントをハンドラで処理できるかのversion
}
public class OrderCreatedEvent: DomainEvent {
    // イベントの名前はより詳細で明確に
}

コマンドはコマンドバスと呼ばれるプロセッサにより管理
イベントはイベントバスと呼ばれるコンポーネントによって管理
コマンドバスはメッセージ(コマンドを実行するリクエストとイベントの通知)を受け取り、それらを処理する方法を見つけ出す単一のclass
- コマンドバスは実際に処理を行うのではなく、処理できるハンドラを選択する
- コマンドと関連するイベントを処理するプロセスはSagaと呼ばれる
Sagaコンポーネントは、論理的に関連するメソッドとイベントハンドラを集めたようなもの
ドメイン層はコマンドスタックに配置され、はるかに単純なデータアクセス層はクエリスタックに配置される
現実のシステムの多くは読み取りと書き込みに単一のDBを使用する
- コマンドモデルとクエリモデルを別々に定義したとしても同じDBを共有することは可能(どうのようなシナリオに取り込むかによる)

イベントバス

bus: データをやり取りするための伝送路
コールバックメソッドを呼ぶタイミングでイベントを発火し、コールバックインタフェースの実装ではなく、イベントを常時監視するメソッドを用意しておいて、発火したタイミングで呼び出されるようにする仕組みとして、EventBus を使うことで、インタフェースによる依存関係を整理したり、コールバック地獄を解消したりすることができる
EventBus という中間層を介したコミュニケーションを用いることで、ModelとControllerは直接結合することがなくなることで、Controllerが実装したコールバックインタフェースの管理をしなくても良くなる

11. CQRSの実装

クエリスタックの実装

クエリスタックのドメイン層がほとんど空でDBに対して実行される単純なSQLクエリとデータにをプレゼンテーション層へ届けるためのDTOだけで構成される
クエリスタックは出来るだけ単純に、上位レイヤーにはDTO(データ転送オブジェクト)を使って返す(それらはViewModel)
読み取りファサードは主にデータモデルとDBコンテキストによって構成される
高階関数で加工すれば、大量のDTOを作成せずに済む

コマンドスタックの実装

コマンドとイベントの観点からワークフローを定義することでアプリケーションのユースケースを実装する
ユーザからの入力などはコマンドバスに渡されるコマンドになる。さらに処理するには、コマンドバスがコマンドを登録済みのハンドラに渡す。コマンドの処理によりさらに別のコマンドとドメインイベントによって前進するプロセスが開始される
- コマンドをワークフローのコンテキストで処理するプロセスをSagaと呼ぶ
  - Sagaはコマンドバスと連携することで、ユースケースを実装するために実行しなければならないタスクの手はずを整える

12. イベントソーシングの紹介

DDDはデータモデルの作成よりもドメインモデルの作成を推奨する
- リレーショナルモデルではエンティティとそれらの関係に焦点を当てる
- ドメインモデルはドメインで観察可能な振る舞いに焦点を当てる
CQRSによりコマンドをクエリから離した瞬間にタスクという観点から考えるようになる
- タスクはドメインイベントとアプリケーションイベントに深く結び付く
イベントソーシングはイベントをツールとして使う
- ドメインモデルではなくイベントを永続化する
- イベント・ソーシングを知る
  
  イベントを中心に考える - 様々な出来事(イベント)の結果、状態が変更する - 状態はイベントの結果にすぎず、本質ではないのでないかという考え方
- イベントを記憶する(状態は記憶しない)
  - 何が起きたかだけを淡々と記憶する
- イベントソーシングの凄い所
  - 完全な履歴が手に入る
  - 任意の時点を再現出来る
- 問題点
  - パフォーマンス(最新の状態を得るため、毎回膨大な量のイベントをリプレイスする必要がある)
  - バージョニング(仕様変更が起きたら過去のイベントをどう処理するか)
  - 実装が複雑(イベントを記憶してリプレイスする機構)

イベントの躍進

イベントソーシングに言わせれば、イベントが発生すればそのイベントに関連付けられているデータの集まりが保存さる
イベントの永続化に対処するには、イベントを記憶するためのイベントストア要素が必要になる

イベントソーシングアーキテクチャ

イベントの再生
- ビジネスエンティティの状態を再現する
- 多くのシナリオでは、イベントの再生は非同期処理の一部
- 多くの場合は、数１０個程度のイベントが対象となる為それほど時間はかからない、それが問題となるならデータスナップショットを使用する
  - スナップショットはシリアライズされた状態の集約を含む、永続キャッシュ

13. イベントソーシングの実装

「最後に確認された正常な状態」ではなく、「発生した出来事」を追跡する方がビジネスとして意味がある場合には、イベントソーシングは妥当なパターンとなる
イベントソーシングの実装 +α
- 追跡を目的としてイベントを記憶する + 対象となる集約の「最後に確認された状態」も保存する

イベントソーシングを使用する理由と状況

イベントソーシングによりシステムの周りで発生するあらゆる事を追跡出来るようになり、アプリケーションロジックが処理するコンテキスト/コンテンツをアーキテクトが推測できるだけの柔軟性が確保出来る
イベントソーシングに適したシナリオ
- データ処理の意図や目的を記録することが要求されるケース
- 記録されているイベントに基づいて何らかのタスクを実行するケース(状態を復元したい、ロールバック)
- イベントソーシングを使用するかどうかを判断する決め手は、ビジネスドメインにおいてイベントを追跡することが妥当であるかどうか
Command Bus

public class Bus
{
    private static readonly Dictionary<Type, Type> SagaStarters = new Dictionary<Type, Type>();
    private static readonly Dictionary<String, Object> SagaInstances = new Dictionary<String, Object>();
    private static readonly EventRepository EventStore = new EventRepository();

    public static void RegisterSaga<TStartMessage, TSaga>()
    {
        SagaStarters.Add(typeof(TStartMessage), typeof(TSaga));
    }

    public static void Send<T>(T message) where T : Message
    {
        // Implement
    }
}

Saga: Eventを処理するプロセス

public class MatchSaga : SagaBase<MatchData>,
                         IStartWithMessage<MatchStartedEvent>,
                         ICanHandleMessage<MatchEndEvent>,
                         ICanHandleMessage<PeriodStartedEvent>
{
    private readonly EventRepository _repo = new EventRepository();

    public void Handle(MatchStartedEvent, message)
    {
        // SagaのIDを設定
        SageId = message.MatchId;

        // 試合情報が更新されている事を通知
        NotifyMathcInfoChanged(message.MatchId);
    }

    public void Handle(MatchEndEvent, message)
    {
        // 試合情報が更新されている事を通知
        NotifyMathcInfoChanged(message.MatchId);
    }
}

// このmessageがbusにpushされるとsagaが起動する
var domainEvent = new MatchStartedEvent(matchId);
Bus.Send(domainEvent);

イベントの永続化 EventRepository
- 通常、イベントはDTO(プロパティ)の集まりであるので、DBのレコードとして簡単に保存可能
イベントの再生
- 記録されたイベントから集約の状態を再現、一連のイベントをループで処理する

public IEnumerable<EventMapper> GetEventStream(String id)
{
    return DocumentSession.Query<EventWrapper>()
                          .Where(t => t.MatchId == id)
                          .OrderBy(t => t.Timestamp).toList();
}

集約snapshotによるイベントソーシング

イベントソーシングは自然な選択でないといけない。イベントを追跡する事が重要でその方が簡単であるなら、イベントソーシングを利用しそこから状態を再現するか、集約をスナップショットとして永続化するか

「Application Architecture for .NET」を読んだ - 3部(前編)

book

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

作者: Dino Esposito,Andrea Saltarello,日本マイクロソフト（監訳）,クイープ
出版社/メーカー: 日経BP社
発売日: 2015/06/04
メディア: 単行本
この商品を含むブログ (2件) を見る

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

第三部サポートアーキテクチャ(8, 9章)のメモ。

TL;DL

ドメインモデル
- エンティティはビジネス空間に関連するオブジェクトであり同一性とライフタイムを持つ
- 値オブジェクトは空間内の無生物とも言える存在
- 一部のエンティティはコーディグや設計上の目的で集約に纏められる
モデリングの際の一番の関心毎ではないものの、DB構造が制約である

3. サポートアーキテクチャ

8. ドメインモデルの紹介

データから振る舞いへの移行

DDDはレコードの代わりにオブジェクトを使ってデータアクセスコードを記述するだけのアプローチではない
ドメインモデルはビジネスのAPI
- クラスを基本的なビジネスコンセプトと一致させ、常に整合性を保つ事 => データより振る舞いに重点を置く
DDDはドメインモデルの作成を優先し、モデリングされたドメインの永続化は後回しにする
- ドメインモデルは永続化に関与しない

ドメイン層の内側

アプリケーション層はドメインとインフラ層を操作するためのオーケストレーションコード
ドメインモデル: エンティティ/値オブジェクトから構成される
- 値オブジェクト: データの集まり, instance化されたら変化しない(Immutable), 属性
- エンティティ: データと振る舞いを持つ, 一意性
  - 振る舞いはドメインロジックとアプリケーションロジックを区別する
    - ユースケースの実装はアプリケーション層に含まれる
    - ex. OrderEntityは税金の計算を行うが、注文の処理はドメインロジックの外側にある => エンティティに関連付けられたユースケースはサービスで実装する
モジュール: ドメインモデルを纏める名前空間
リポジトリ: エンティティの永続化
- 契約(コンストラクト)はドメイン層、実装はインフラ層

集約

モデル内のエンティティを纏めたり区切ったりする整合性の境界
ドメインモデルでは、複数のモデルを1つのコンテナに纏めたものを集約と呼ぶ

「集約とは、データを変更する目的で1つの単位として扱われる、関連するオブジェクトの集まりです」
値オブジェクトはエンティティから参照される為、集約の一部。複数のエンティティから参照可能で複数の集約で使用可能
エンティティが参照できるのは、同じ集約内のエンティティか、別の集約のルートだけ
集約のルートの責務
- カプセル化されている全てのオブジェクトの永続化に対する責任
- クエリ操作で取得できるのは集約のルートだけ、内部オブジェクトへのアクセスは集約のルートのインターフェースを通じて発生しなければならない

// 集約ルートを示すmarker
// 集約ルートだけがリポジトリを持つ、リポジトリの型制約として使う
public interface IAggregateRoot {
    bool CanBeSaved { get; }
}

public class Order: IAggregateRoot {
    bool IAggregateRoot.CanBeSaved {
        get { return validate(); }
    }
    // ...
}

ドメインサービス

ドメインロジック(特定の集約に属さない、ほとんどの場合複数のエンティティにまたがっている)を実装するメソッドを持つクラス
- 特定のビジネスロジックが既存の集約のどれとも適合しなかった場合の最後の砦
- ドメインサービスのインターフェースはユビキタス言語で書かれた契約(コントラクト)を表し、アプリケーションサービスから呼び出せるアクションを定義する
- 集約をまたいだ振る舞いに用いる
リポジトリ
- 永続化の為に存在する
- CustomerRepositoryのように集約ルート毎にリポジトリを１つ使用することになる

public interface IRepository<T> where T: IAggregateRoot {
    // interfaceを単なるmarker interfaceにしても良いし、一般的なメソッドを幾つか定義することも出来る
    T Find(object id);
    void Save(T item);
}

ドメインイベント
- ~の「とき」に着目 - ドメイン内に関連するイベントがあるはず
  - 特定の事実が発生したタイミングを知ることにビジネス上の関心があることを示す

public interface IDomainEvent {}
public class CustomerReachedGoldMemberStatus: IDomainEvent {
    public Customer customer { get; set; }
}

横断的関心事
- 階層化アーキテクチャでは具体的なテクノジに関連するものはInfrastructure層に含まれる
- CRUD操作は主にリポジトリを通じてコーディグされ、ドメインサービスとその上にあるアプリケーション層を通じて結合される
- ドメインモデルのクラスではチェックできる物は何でもチェックするようにし、問題が検出された場合は特別な例外をthrowすべき
- => 例外のエラーメッセージを上位レイヤーに渡し、アプリケーション層ではドメイン例外をそのままプレゼンテーション層に渡すか、飲み込んでしまうか判断する
  - 実際のエラーメッセージはプレゼンテーション層の責務となる

9. ドメインモデルの実装

実用的なドメインモデルを作成するための護身術

ドメインモデル貧血症
- エンティティが貧血と判断されるのは、エンティティに属しているものの￥、エンティティクラスの外側に配置されているロジックがある場合
  - ex. メソッドがエンティティのメンバーのみを扱う場合は、そのエンティティに属している DateTime EstimatedPayment(Invoice invoice)
エンティティのscaffolding
- DDDのエンティティの特徴
  - 同一性が明確に定義されている
    - アプリケーションのライフタイムに渡ってエンティティを一意に識別する目的
  - 振る舞いがpubli/非publicメソッドによって表現される
    - 状態を変更できるメソッドをユビキタス言語と一致させるように提供する
  - 状態が読み取り専用のプロパティにより表現される
  - プリミティブ型の使用は限定的で値オブジェクトと置き換えられる
  - 複数のコンストラクタよりもファクトリメソッドが優先される
値オブジェクトのscaffolding
- エンティティ同様にデータを集約するクラス(振る舞いとは無関係)
- 値オブジェクトは可変の状態を持たず、データによって完全に識別されるため、同一性を必要としない
- メソッドを定義することは可能だが、それらは状態を変更しない純粋なヘルパーメソッド
- 値オブジェクトの利点は表現性
  - プリミティブ型だと曖昧すぎる
  - データクランプ(新しいオブジェクトに簡単に変換出来るプリミティブ値の集まり)
集約の特定
- 特別なケース
  - スペシャルケース - Strategic Choice
モデルの永続化
- 役目を果たすのはO/RM
  - CRUD
  - Query Engine
    - クエリーオブジェクト - Strategic Choice
  - Transaction Engine
    - ユニットオブワーク - Strategic Choice
  - Concurrency
- 最初はユビキタス言語の特徴と一致する理想的なドメインモデルの作成を目指す、その後それを永続化するのに最適なORMに適したものにするのを目指す

2015-11-08

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

book

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

作者: 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

独自のユビキタス言語とアーキテクチャを必要とするアプリケーション領域
- 問題空間のサブ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
- ユーザが操作出来る操作に焦点を合わせ、リクエスト毎にメソッドを作成する
- ビジネスロジックがトランザクションスクリプトに基づいて実装されているとシステムの階層化アーキテクチャーはコンパクト(スキーマは従来の3層構造のアーキテクチャーと同様)
  - 適しているのはビジネスロジックがそんなに複雑ではない単純なシナリオ
  - システムをコマンドとクエリの2つの部分に分割すると、コマンド部をTSにで簡単に実装し、クエリ部に対する効果的なモデルの準備に注力する
  - スクリプト間でのデータのやり取りはDTO(データ転送オブジェクト)を使用する
Domain Model Pattern
- 期待される振る舞いと、動作させるデータの流れに焦点を合わせるアーキテクチャー(クラスという概念から再現する)
- Domainについて知れば知るほどそれをソフトウェアで模倣しやすくなる
  - エンティティのプロパティよりもアクションに目を光らせる => 振る舞いを突き止めるのに役立つ(Tell Don't Ask)
- ADM(Anemic Domain Model)(アンチ) Pattern
  - エンティティに含まれているのはプロパティだけで振る舞いがない

データからタスクへの焦点の移動

Domain内でのタスクオーケストレーション
- ビジネスロジックにはタスク、ドメインロジック、その他(ドメインサービス)のオーケストレーションが含まれている
  - ドメインサービスは、エンティティに収まらないロジック、複数のエンティティに関連する操作が含まれているなど
  - ドメインサービスとして定義される操作はステートレス
    - 何らかのデータを渡し、何らかのレスポンスを受け取る。状態は一切管理されない
      境界を跨いだデータの移動
ドメインモデルに存在しないデータの集まりをユーザインターフェースに持ち込みたいかもしれない etc => DTOを使う
- DTOは振る舞いを持たない単純なコンテナ
  - エンティティからDTOを作成する
  - AutoMapper, Adapter

Mapper.CreateMap<Source, DTO>
var dto = Mapper.Map<DTO>(sourceObj)

2015-11-03

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

book

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

作者: Dino Esposito,Andrea Saltarello,日本マイクロソフト（監訳）,クイープ
出版社/メーカー: 日経BP社
発売日: 2015/06/04
メディア: 単行本
この商品を含むブログ (2件) を見る

古めですが、ここに参考文献が上がっています
matarillo.com: .NETのアプリケーションアーキテクチャ

第一部基礎編のメモ。

TL;DL

アーキテクチャとはシステム開発の利害関係者（ステークホルダー）全体にまたがる共通理解を指す

システム開発の利害関係者は、それぞれが異なった要望や関心事を持っている
- 大まかに分類すると、利用者の領域、ビジネスの領域、そしてシステムの領域となる。それぞれはトレードオフの関係にあることも多いため、アーキテクチャはこれら3つの領域のバランスを取ったものになっていなければならない

1. 現代のアーキテクトとアーキテクチャ

アーキテクトは役割
- ≒ Lead Developer
- Architect extends Developer
アーキテクチャは顧客のためのシステムを構築するもの
- 明確な答えはないが、見つけ出すことは仕事
- 良いアーキテクチャ: 変更が困難な決断が全て適正なものであることがわかる
重要な決断を下さなければならないことがアーキテクチャ
- プロジェクトの出来るだけ早い段階で正しく下さなけばならないもの(先送りにしたいもの)

2. 成功のための設計

ソフトウェアプロジェクトの最大の敵はBBM
- BBM(ビッグ・ボール・オブ・マッド) --「大きな泥だんご」 => 特盛のスパゲッティコード
成功するソフトウェアプロジェクト
- ビジネスニーズを理解し、そこから上手くいくソリューションを引き出すプロジェクト
上手く設計されたソフトウェア
- 成功するプロジェクトを背景とし、既存のコードとインフラストラクチャを再利用した上で設計され、利用可能なテクノジと既知のベストプラクティスを踏まえて改良されたソフトウェア
ボスは追従者を生み、リーダーは他のリーダーを生む
マネージメントチームがリーダーシップを理解していてる + 開発チームがコードの品質について理解している == プロジェクトを成功に導く
リファクタリングはプロジェクトに価値を生み出さないけど、行わないと価値が失われる
Legacy Code: 側に置いてはいるが、側に置きたくないコード
- testが書かれていない == Legacy Code
- 幅広く利用されているため、置き換えるのが難しい
- これ以上、Legacy Codeを増やさないようにするのが問題
切り離されたブロック(black box) == 境界付けられたcontext

3. ソフトウェアの設計原則

ソフトウェアアーキテクチャでは、柱の周りに振る舞いを実装することが鍵

基本的な設計原則

凝集性: 密接に絡み合った責務 - 高いのが理想
- 単一責任の原則
結合性
- AクラスBクラスの結合の度合い - 低いのが理想
内蔵型のobject(高凝集)が安定したinterfaceを通じて他のobjectとやり取りする(疎結合)ことを意味する
関心の分離 - AOP

オブジェクト指向設計(OOD)

関連のあるobjectを見つけ出し、相互にやり取りするobjectの結合性を最小限に抑え、コードを再利用する
合成と継承
- 派生classは親classのコードを継承するだけではなく、contextを警鐘し、そこから親classに対する可視性を手に入れる
- 合成は防御的
関心の分離
- 変化する可能性が高い部分を切り出す
- classが必要でないことがある。関数だけで良いなら、それを使用するだけにする
- 現実の世界がモデルではなく、イベントを表す、イベントがデータを運ぶもの

開発ベクトルと設計ベクトル

SOLID原則
- 単一責務の原則(SRP)
  - 責務とは変更の理由のこと
  - 限界まで追及するとプロパティだけの貧血classになる危険がある
- 開放/閉鎖の原則(OCP)
  - 拡張に対して開いている / 修正に対しては閉じたまま
  - composite / interface / generics
- リスコフの置換原則(LSP)
  - classを作成するとしたら合成の方が安全
  - サブclassをその基底classと置き換えることが出来ないといけない
    - 派生classはその基底classよりも多くのことを要求すべきではなく、それ以下のものを提供すべき
    - class継承のcontextで「特殊な」という表現がされたら注意する
- インターフェース分離の原則(ISP)
  - クライアントが使用しないinterfaceにクライアントを強制的に依存させてはならない
- 依存関係逆転の原則(DIP)
  - 上位moduleを下位moduleに依存させるのではなく、両方のmoduleを抽象化に依存させるべき
    - Service Locator
    - Dependency Injection(constructor / setter / interface)
coding vector
- プログラミング原則一覧 - Strategic Choice
- KISS(keep it simple, stupid)
  - 完璧とは、付け加えるべきものがなくなった時ではなく、取り去るべきものがなくなった時のこと
- YAGNI(you ain't gonna need it)
- Tell, Don't Ask
  - Tell, Don't Ask [ 求めるな、命じよ ] - はむはむエンジニアぶろぐ

4. 高品質なソフトウェアの作成

テストされていないものは壊れていると思え
どのようなシステム、どのようなcontextにおいても単純さは常に長所
依存関係を排除するテスト
- テストダブル(fakeとmock)
  - fake object: objectの比較的単純なcopy(元のobjectと同じinterfaceを提供する。状態は無くハードコーディングされているケースが多い)
    - やり取りに関心は無い
  - mock object: fake object + 独自の特性を持つobject
TDDのテストの最終目的はカバレッジを広げることでは無く、「設計を改善する事」
- テストは目的では無く、良い設計を実現するための手段
applicationのロジックを左右する重要な決断が下される場所(ビジネス層/ドメイン層)で、テストを重点的に行なうべき
codeの拡張性
- 早まった拡張はソフトウェアの諸悪の根源になりかねない(過剰性能)
読み易さは主観的な問題
- coding以外の事をする十分な時間がない事を承知しているなら、最初から読み易いコードを書くように
code comment: codeにおいて下される自明ではない判断について説明する文(特定の部分関する洞察に満ちた見解)
code品質
- テスト容易性/拡張性/可読性

2015-10-25

「Kent Beckの実装パターン」を読んだ

book

実装パターン

作者: ケント・ベック,Kent Beck,永田渉,長瀬嘉秀,株式会社テクノロジックアート
出版社/メーカー: ピアソンエデュケーション
発売日: 2008/12/22
メディア: 単行本（ソフトカバー）
購入: 30人クリック: 502回
この商品を含むブログ (91件) を見る

メモです。リーダブルコードをより具象化、パターン化した本という印象。

TL;DL

「他人が読んでわかるコード」が「よいコード」
読み手を意識しながらコーディングすることの重要性。いかに意図を正しく伝えるか

プログラマの仕事は，他のプログラマとの間でコミュニケーションを取ることである．マシンとではない．

Implementation

実装パターン

「相手にこのコードで何を伝えたいか」を自問する思考方法
誇りの持てないものに対して無駄にする時間はない、よいコードを書くこと自体が喜びであり、そのコードを他の人が理解し、評価し、使用し、拡張してくれれば、さらに喜びは増す

「責任」についての本

自分とその相棒であるマシンのためだけではなく、他の人のためにコードを作成する

コードを通して考えを伝える

自分で何を考えているを意識出来るくらいに思考速度を落とす == 直感でコードを書く振りを止める
他人の重要性を認識する

卓越したプログラムに必要とされる要素　- 動機

コミュニケーション
- 他の人はこれを見てどう感じるだろう
シンプル
- 余分な複雑性を取り除き、本質を目立たせる
柔軟性
- 複雑を引き起こさない、シンプルから生まれる柔軟性

原則 - 行動

結果の局所化
- 変数のコストを低く
繰り返しの最小化
- 小さな部品を作る
ロジックとデータの一体化
- ロジックが操作するデータは近くに
対称性
宣言型の表現
- 型に意図を詰める
変更頻度
- 同じタイミングで変更されるデータは近くに

Class

classの名前が決まれば操作の名前は後から決まってくる
- 短く力強く、意味が豊富で的確な
Interfaceとクラス階層は相互排他ではない
新しいSubInterfaceを導入することでInterfaceの拡張を安全に行う
状態を持たないVOで暗黙的なシーケンスを無視する
static関数を格納したライブラリクラスはいつでもオブジェクトクラスに変換できるように
classは関連する状態を一つに纏めるもの

State

オブジェクトは、外部の世界に示される振る舞いと、その振る舞いを支えるために使用される状態のパッケージ
似たような状態(近くにあるか、同じ計算で使われている、発生・消滅のタイミングが同時か)は1つに纏め、異なる状態は離しておく
flagに基づいて決定を行うコードが重複しているならstrategyパターンを検討する
static fieldと引数の両方を使用できるなら引数でクラス間の結合を行う
変数の生存期間、スコープ、型は、コンテキストで伝えることが出来る
変数やメソッドを出来るだけ汎用的な型で宣言する
- 後から具象クラスを自由に変更できる

Behavior

実装を選択するためのメッセージを広範囲に使用すると、明示的な条件分岐のないコードになる(実行時の型に基づいて)
自分の意図をより明確に伝えるために説明メッセージを用いる

Method

出来るだけ汎用的な型で戻り値を宣言する
複雑なオブジェクト生成をコンストラクタではなく、ファクトリー(static method)に任す
- コンストラクタは具象クラスに貼り付けるので、ファクトメソッドでコードの抽象度が上げる
  - 抽象的な型を返すことが出来る
  - 意図にあった名前を付けることが出来る
  - ファクトリーの中で何をやっているのか気になるので、オーソドックスな生成だけならコンストラクタを用いる
メソッド名では意図を伝達し、実装戦略が重要でないなら含めないべき(呼び出し側がどう見えるかによって命名する)
公開するものを少なくすることにより得られる柔軟性を重視する
privateなヘルパーメソッドでサブルールンを隠蔽する + 共通部分を除去する
変換処理は変換後のオブジェクトに変換用のコンストラクタを定義する

Collection

Collectionを継承するより委譲を活用するのが良い
- 意味のある操作だけ公開し、わかりやすい名前を付ける事が出来る
- 継承だと、不適切な(意図しない)メソッドまで保持することになる(ex. clear)

class Library {
    Collection<Book> books = new ArrayList<>();
    // ...
}

Extended to Framework

clientのコードを壊すことなくFWの改善が行えるようにするためには複雑性が増すことの方がコスト的に有利な事がある
clietnにはシンプルなインターフェースを提供する
目標のFWは、進化可能なくらい複雑だが、使用するのには十分シンプルであり。進化可能なくらいに応用範囲は狭いが、使用するのに十分適応範囲が広い
公開される詳細の数を減らし、変更される確率の低い詳細を公開する

何が価値を生むか

output

転職

引っ越し

まとめ

来年

TL;DL

10. CQRSの紹介

コマンドとクエリの分離

クエリスタック

コマンドスタック

イベントバス

11. CQRSの実装

クエリスタックの実装

コマンドスタックの実装

12. イベントソーシングの紹介

イベントの躍進

イベントソーシングアーキテクチャ

13. イベントソーシングの実装

イベントソーシングを使用する理由と状況

集約snapshotによるイベントソーシング

see also

TL;DL

3. サポートアーキテクチャ

8. ドメインモデルの紹介

データから振る舞いへの移行

ドメイン層の内側

集約

ドメインサービス

9. ドメインモデルの実装

実用的なドメインモデルを作成するための護身術

TL;DL

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

DDDの本当の付加価値

ユビキタス言語

境界付けられたcontext

階層化アーキテクチャ

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

ユーザーエクスペリエンスファースト

シナリオ

7, 伝説のビジネス層

データからタスクへの焦点の移動

境界を跨いだデータの移動

TL;DL

1. 現代のアーキテクトとアーキテクチャ

2. 成功のための設計

3. ソフトウェアの設計原則

基本的な設計原則

オブジェクト指向設計(OOD)

開発ベクトルと設計ベクトル

4. 高品質なソフトウェアの作成

TL;DL

Implementation

実装パターン

「責任」についての本

コードを通して考えを伝える

卓越したプログラムに必要とされる要素 - 動機

原則 - 行動

Class

State

Behavior

Method

Collection

Extended to Framework

see also

卓越したプログラムに必要とされる要素　- 動機