軍事思想_作戦術_で整理するドメイン駆動設計___DCIアーキテクチャ.pdf

Transcript

1. 軍事思想(作戦術)で整理するドメイン 駆動設計 + DCIアーキテクチャ
2. 主旨 オブジェクト指向を使用したプログラミング設計方法であ るMVCモデルやドメイン駆動設計はプログラムを構成す る各要素をクラス化し、配置することに重点が置かれて いる。 しかし、これらの設計方法では、プログラムの流れを直観 で理解するという思考が欠けているため、プログラムの ソース全体を解読してからでないとプログラム全体の動き が理解できない。 しかしこの方法では、ユーザーの要求が上がるにつれプ ログラムソースは複雑化し、プログラムのソースを解読し てプログラム全体の動きを理解するという作業は難易度 が上昇していく。
3. 主旨 プログラムの流れを直観で理解できるようにするために は、従来の機械的なIT業界の発想からではなく、別業界 から直観的でダイナミックな思想を取り入れなければなら ない。 よって、ダイナミックな要素で構成される戦争という現象 を研究する軍事思想から理論を拝借し、最新のプログラ ム設計方法であるドメイン駆動設計と組み合わせること で、プログラムを直観で理解できる理論を構築したいと思 う。
4. 本旨に入る前に 本旨に入る前に前提知識となる用語について事前 説明を行いたいと思う。
5. 前提知識・・・ドメイン駆動設計 MVCモデルを進化させた開発手法。 コントロール層、ユースケース層、ドメイン層、インフ ラ層の4つの層に分割して開発を行う。 データの構造、共通の業務知識をドメイン層に配置 し、ドメイン層内部に共通ロジックを閉じ込めること で、堅牢で拡張性が高いプログラム開発を行うこ とできる。
6. 前提知識・・・DCIアーキテクチャ データ(Data)、コンテキスト(Context)、インタラクショ ン(interction)の3つのクラスを使用して、特定の ユースケースによって動作が変更される共通のビ ジネスロジックを記載する。 カメレオンが色を変わることを想像してほしい。 カメレオンという本体は変わらないが、状況によって 変更する色は変化する。 状況を表すロジックがコンテキスト、色を表すロジッ クがデータ、カメレオンが青色に変更するというロ ジックはインタラクションということになる。 ScalaではTrait、JavaではMixinを使用して実装が 行われる。
7. 前提知識・・・IDAループ 航空戦術家であるジョンボイドが提唱した、意思決定理論で あるOODAループを簡略化したもの。 意識決定のファクターを以下の3つに分類 ・ファクター 　・Information(情報) 　・Decide(決定) 　・Act(実行) Information、Dcide、Actの順番でループを高速に回転させ ることで素早い意識決定を実現する。
8. 前提知識・・・戦域レベル、作戦レベ ル、戦術レベル 戦争を行う順番を階層レベルで分類したもの。 ・大まかな定義 戦域レベル・・・バトルフィールド。 作戦レベル・・・戦争の目的を達成するための行動計画を立 案し、戦術レベルで行動計画を実行する。 戦術レベル・・・作戦レベルで考案された行動計画を達成す るための具体的な手段や方法を定義し、戦闘を実行す る。
9. 前提知識・・・作戦レベルにおける行 動計画の分類 作戦レベルにおける行動計画は以下の種類に分類すること ができる。 偵察作戦・・作戦を計画通りに実行できるか事前調査。 順次作戦・・・決定された順番に従って、作戦を実行。 ゲリラ作戦・・・突発的でランダムな作戦を実行。 監視作戦・・・支配するエリアで想定外の行動を行っていな いか調査。 エスカレーション作戦・・・ルールに従わない対象を強制的に 服従させる。 エマージェンシー作戦・・・緊急事態に対応する行動。 相対作戦・・・順次作戦に対する例外的な行動。
10. ここから本旨の説明に入りたいと思う。 以下のアジェンダに従って説明を行う。 1.理論編 1.1.プログラムのレイヤー構成 1.2.各レイヤーの説明 1.3.レイヤー説明に関する疑問点 2.ドメイン駆動設計を実装する際の具体的な例を紹介 2.1 ドメイン駆動設計を実装する際の必要なツール 2.2 開発環境 2.3 各層に実装するクラスの種類 2.4 実装時の注意点
11. 理論編
12. プログラムのレイヤー構成 インフラ層 コントロール 層 ユースケース層 ドメイン層 戦域レベル 作戦レベル 戦術レベル・・・ DCIアーキテク チャ
13. 各レイヤーの説明・・・コントロール層 アプリ外からアクセスの入り口となるインターフェー スを主にRestApiで提供する。アプリ外からのアクセ スがWeb、iOS、Androidと増加するたびにインター フェースを追加する必要がある。 インターフェース以外の機能として、コントロール層 からユースケース層へデータを受け渡す際のデータ 変換、コントロール層からアクセス元へのデータ変換 (JSON化)を行う。データの受け渡し、データ変換機 能をメインに担当する。
14. 各レイヤーの説明・・・ユースケース層 ビジネスロジックをメインに担当する。ビジネスロジックは戦 域レベル、作戦レベル、戦術レベルの三段階に分割して実 現する。 各レベルでは以下のようなロジックをそれぞれ担当する。 戦域レベル・・・画面アクセス許可のチェック、画面の入力値 チェック、ユースケース事前条件のチェック、作戦レベルのメ ソッドを呼び出しなどを担当。 作戦レベル・・・戦術レベルのメソッドを順番に呼び出 す、Facade クラス。作戦の目的別にクラスの分類分けを行 う。 戦術レベル・・・作戦レベルの目的を達成するための具体的 な手段を提供する。DCIアーキテクチャで実装が行われる。
15. 各レイヤーの説明・・・ユースケース層 ユースケース層で実施される作戦レベルのビジネスロジック を目的ごとに以下のように分類する。 偵察・・・画面に表示するデータを取得する 順次・・・ビジネスのワークフローを順番通りに進める ゲリラ・・・不定期に行われるイベント処理を実施する 監視・・・DB内部の情報を監視し、アプリの規約に違反した ユーザーの発見などを行う エスカレーション・・・アプリのルールに違反しているユー ザーへの通知、警告などを行う エマージェンシ・・・緊急事態に対応する 相対・・・キャンセル処理などビジネスのワークフローから外 れる例外処理
16. 各レイヤーの説明・・・ドメイン層につい て ドメイン層では、アプリ全体で共通するデータ構造の 取得、共通するデータ構造に依存した業務ルールの 提供などを取り扱う。 ドメイン層では、ドメイン層以外のレイヤーから呼ば れることを前提としているため、データの登録、更 新、削除処理を記述しない。
17. 各レイヤーの説明・・・インフラ層につ いて 外部ライブラリを使用したロジックを記述し、全レイ ヤーに外部ライブラリの機能を提供する。例として メールの送信、ログの出力などが該当する。 ライブラリはバージョンアップや使用するライブラリ変 更されるなど、頻繁に発生する箇所する。そのた め、DIP(依存関係逆転の原則)に従って、 ドメイン層にインターフェースを配置し、実際のロジッ クはインフラ層に記述する。インターフェースをデー タインジェクション(依存性注入)機能を利用してイン タンス生成を行う。
18. ユース―ス層を3つに分割する理由 1.コントロール層の役割の明確化・・・ コントロール層ではインターフェースをシステム外か らアクセスする環境ごとに用意する必要があるた め、画面の入力値チェックなどを記述してしまうと インターフェースの数だけ入力値チェックが必要と なる。画面の入力値チェック処理をユースケース 層の戦域レベルの処理に寄せることによって、コン トロール層に外部からのアクセスを提供するイン ターフェースの機能のみ集中することができる。
19. ユースケース層を3つに分割する理由 2.IDAループを実行・・・ IDAループとは、「Information・・・情報」「Dcide・・・決定」 「Act・・・実行」の頭文字をとったものである。 ビジネスロジックにおけるIDAループとは「ビジネスロジック の事前実行条件の確認」「Decide・・・ターゲットとなる顧 客のレベルを特定」「Act・・・顧客レベルに応じたビジネス ロジックの実行」となる。 IDAループは「Information」は戦域レベル、「Dcide」は作戦 レベル、「Act」は戦術レベルで実行する。ビジネスロジック にIDAループを導入することで、ビジネスロジックの役割を 明確化することができる。
20. ユースケース層を3つに分割する理由 3.ビジネスロジックを実行する目的の明確化・・・ ビジネスロ ジックは、ビジネスにおける目的を達成するため のソース を記述する。しかし、ビジネスにおける目的は多 岐に渡る ため、一つのメソッド内に多数の目標を達成す るロジック を集中して記述してしまう。これがロジックの複 雑化を引き 起こし、ソースの可読性の低下、メンテナンス 性の低下を 引きおこす。そのため、ビジネスにおけるビジ ネスロジック は目的ごとに分離されなければならない。 ユースケース層の作戦レベルでビジネスロジックを目的ご と に分類し、ビジネスロジックがどのような目的を達成す る ために記述されているか明確化する
21. ユースケース層を3つに分割する理由 4.ドメイン駆動設計のメソッドの使用目的の明確化・・・ 従来のドメイン駆動設計では、ドメイン層のメソッドはユース ケース層内で呼び出されていることを想定されている。 しかし、ユースケース層内で役割分担がまったく整理されて いないため、ドメイン層からどのようなメソッドを呼び出せ ばよいのか、実装するプログラマーに一任していた。 そこで、ドメイン層からValueObjectクラスのリストの生成を 行うメソッドを戦術レベルのDCIアーキテクチャクラスの Intractionクラス内でのみ呼び出すようルールを設ける。 DCIアーキテクチャは、Contextクラスで特定のビジネスロ ジックのシーンを切り出し、提供する。Contextがドメイン 層のメソッドを使用する目的を作りだすため、プログラマー はドメイン層のメソッドがなぜ使用されるのかイメージする ことができる。
22. ドメイン駆動設計を実装する際の具体 的な例を紹介 • ドメイン駆動設計へ理論編で紹介した内容を実装 する際の具体的な例を次のページから紹介した いと思う。
23. ドメイン駆動設計を行うために必要 ツール 以下の条件を満たすフレームワークであれば、どん なツールでも実装可能 1.オブジェクト指向であること 2.DI(依存性注入)を行なえること 3.AOP(横断的関心事)を使えること 4.Nugetやpom.xmlといったコンパイル時に外部ライ ブラリをダウンロードする機能が備わっていること
24. 開発環境 ドメイン駆動設計を実装するための開発環境として、 以下の開発環境を想定 統合開発環境・・・Eclipse 開発言語・・・Java9 フレームワーク・・・Spring Boot DB・・・SQL Lite
25. コントロール層・・・実装するクラス一 覧 コントール層は以下の要素で構成される Controller・・・REST APIの提供、Convetクラスのメソッドの 呼び出し、ユースケース層の画面レベルのメソッドの呼び 出し、 Web用、Andoroid、iOSへ引数を返却する際の値変換 (JSON化)など Coverter・・・REST APIから取得した画面の入力値の値を ユースケース層へ引き渡す際の値の変換 Bean・・・コントロール層から取得した入力値を格納して、 ユースケース層へ引き渡す際のクラス。getter setterでメ ソッドを構成。表示画面と1対1の関係にある。
26. ドメイン駆動設計の誤り エリックエヴァンスの定義したドメイン駆動設計の Repositoryクラス内部にデータ登録、更新、削除処理まで 含めてしまったため、ドメイン層に複雑性が発生してしまっ た。 そもそも、データ登録、更新、削除処理はDBのデータを変 更するため、慎重な対応が要求されるため、処理自体が複 雑なものになってしまう。しかし、データ登録、更新、削除処 理を目的とする処理というのは、特定のユースケースに依 存する。特定のユースケースに依存する処理を共通の処理 を記載するドメイン層に記載するというのは、不適切だと思 われる。 よって、データ登録、更新、削除処理はDCIアーキテクチャ に一任し、ドメイン層は共通したデータ構造の提供、ビジネ スルールの提供に専念する。
27. ドメイン層 ドメイン層を構成する要素 Specification・・・仕様クラス。ここでロジックに関する仕様をif文 で定義し、仕様を満たしているか判定を行う。 Factory・・・DTOクラスを引数とし、ValueObjectインスタンスを生 成 ValueObject・・・共通構造クラス。DTOをフィールド変数として持 ち、getterメソッドとisメソッドのみで構成されている。DTOの データを加工して提供、DTOのデータに応じたif分の提供など を行う。 Repository・・・DBからデータ検索処理を行い、データ検索結果 をDTOで受け取りValueObjectを組み立てる。 Aggregate・・・Repositoryクラスの生成、メソッドの提供を行う。 TableState・・・テーブルの状態を定義する。テーブルの状態に 該当するDTOインスタンスの生成を行う。
28. ユースケース層・・・実装するクラス一 覧 ユースケース層は以下の要素で構成される DisplayArea・・・アクセストークンのチェック、画面へのアク セス許可チェック、Beanの入力値チェック、IDAループの Informationクラスのメソッド呼び出し、Operationのロジッ クを呼び出し Operation・・・作戦レベルのユースケースを記載。 Decideクラスの実行。実行するDCIアーキテクチャクラス、メ ソッドの判断、DCIアーキテクチャクラスの戻り値の結果 から特定のデータの抽出を行う。
29. ユースケース層・・・実装するクラス一 覧 Operationクラスの種類 SearchOperation・・・偵察を目的としたビジネスロジック RegularOperation・・・順次を目的としたビジネスロジック GuerrillaOperation・・・ゲリラを目的としたビジネスロジック MonitoringOperation・・・監視を目的としたビジネスロジック EscalationOperation・・・段階的抑止を目的としたビジネス ロジック EmergencyOperation・・・緊急事態対応を目的としたビジネ スロジック IrregularOperation・・・従来のワークフローから外れた例外 対応を目的としたビジネスロジック
30. ユースケース層・・・実装するクラス一 覧 IDAループ関連クラス Information・・・DBからデータを取得し、ユースケース事前 条件のチェックを行い、条件を満たさなかった場合、処理 を終了する Decide・・・意識決定を行うクラス。顧客情報のレベルの特 定などを行い、作戦レベルで実行するDCIアーキテクチャ のメソッドに意識決定結果を引数として引き渡すことで、 戦術レベルで実行されるDCIアーキテクチャのメソッドに 分岐処理を発生させる。 ＊IDAループのActに該当する役割はDCIアーキテクチャク ラスが担当するため、Actクラスは作成しない。
31. ユースケース層・・・実装するクラス一 覧 DCIアーキテクチャ関連クラス • RegistartDto・・・Roleクラスで登録処理を実施する際の 値を格納するクラス • Context・・・RegistartDto、Decideクラスの意識決定結 果を引数として受け取り、Actorクラスのインスタンス生 成、Decideクラスの意識決定結果をふまえた実行する Roleメソッドの選択を行う • Actor・・・Roleインターフェースを実装するラス • Role・・・インターフェース。Mixinを使用して多重継承を実 施。ドメイン層のメソッドの呼び出し 又は RegistartDtoに 格納された値の入力チェック後のデータ、登録、更新、削 除などを記述。
32. インフラ層・・・実装するクラス一覧 ライブラリーをラッピングしたクラスを実装。状況に応じて 実装するクラスは変化する。 <例> • Log・・・ログ出力を行う • Mail・・・メール送信を行う • Ftp・・・Ftp通信を実施