1. What is Architecture

2. アーキテクチャの種類

特徴

クライアント -> サーバ -> DB のように、層に分けるパターン。名前空間の分割、各レイヤの依存関係、責務の明確化。

問題点

ドメイン層がインフラ層に依存するため、ドメインの実装が、インフラ層の実装に依存してしまう。

解決策

DIP(Dependency Inversion Principle)を用いる。
インフラ層の実装をドメイン層の抽象に依存させ、ドメイン層を独立させる。

特徴

システムを内部と外部の領域に分け、外部からの入力をアダプタが変換し、内部のAPIの形式に合わせる。
テスト用のアダプターが容易に作れる点が利点。クライアント、永続化の種類が未定のうちから、暫定的なアダプターを作ればドメインの実装を進められる。

原則	説明
Standardized Service Contracts	サービスは契約(インターフェース)によって説明される
Loose Coupling of Service	疎結合であり、外部への依存は最低限にする
Service Abstraction	インターフェース(契約)のみ公開し、内部の詳細は見せない
Service Re-Usability	実装は一つで、他サービスから再利用可能である
Service Autonomy	サービスが独立して存在し、一貫性と信頼性を保っている
Service Statelessness	サービスを利用する側が状態を管理する
Service Discoverability	サービスをメタデータで記述し、発見可能にする
Service Composability	サービスはより大きなサービスの一部に組み込み可能である

RESTに従っていることをRESTfulと呼ぶ。

point1 リソースはURI(Uniform Resource Identifer)により、一意に識別される。
point2 一つのHTTPリクエストに、サーバ側での処理に必用な情報を全て含める。サーバは個別のリクエストに依存しない。
point3 全てのオブジェクトが同じインターフェースを持ち、決められたメソッドで操作される。(特に重要なメソッドとして、GET, PUT, POST, DELETE)
point4 レスポンスに他のリソースの情報を埋め込める。Hypermedia as the Engine of Application State(HATEOAS)

RESTとDDDをどう組み合わせるか? ドメインモデルをRESTful HTTPで直接公開するのは悪手。ドメインモデルに手を加えるたびに、システムのインターフェースにも手を加える必用が出てくる。

システムのインターフェースレイヤを、境界づけられたコンテキストとして分離する方法が一般的に使われる。

解決したい課題

What is CQRS?

「更新」を行う「コマンド」と、データを「参照」する「クエリ」に、異なるモデルを使うアーキテクチャ。

アクションを実行する「コマンド」と、データを呼び出し元に戻す「クエリ」をメソッドとして分離するという、 CQS(Command Query Separation)の考えを、アーキテクチャに持ち込んだもの。

f:id:yktm31:20210606192406p:plain

CQRSのメリット - スケーリング - 読み取り、書き込みそれぞれを個別にスケーリングできる。

CQRSのデメリット - 複雑さ - イベントソーシングが含まれる場合、特に設計が複雑になりやすい。

cat phone_numbers.txt | grep 303 | wc -l

上記のLinuxコマンドのパイプ・フィルターのように、イベントを送信->イベント受信->処理実行->イベント送信という流れを、システム間のやりとりとして表現する方式。

業務プロセスにおけるアクティビティの発生をモデリングしたものになる。

パイプ&フィルターを拡張したもの。複数の処理を分散して処理したい場合に利用。

長期プロセスの設計方法

実行者コンポーネントに、各タスクをトレースさせる。
パートナーアクティビティという方法。Pat Hellandが推奨。
イベントを運メッセージに、プロセスの状態を保持させ、プロセスはステートレスとなるように設計する。メッセージを受け取るハンドラが、受け取ったイベントに情報を付与して、次のメッセージとして送出する。