改めて整理するアプリケーション設計の基本

●発表のアーカイブ動画はこちら：https://youtu.be/4rgGkoyUaZw

●発表の中で紹介しているUdemy講座：https://www.nextskill.co.jp/courses

===

プログラミングの基礎を学び、アプリケーション開発に実践的に関わり始めると、「MVC」「サービスクラス」「ドメインモデル」「クリーンアーキテクチャ」といった、よく分からない単語に遭遇します。

これはいわゆる「アプリケーションアーキテクチャ」という分野の話で、アプリケーション開発に関わり始めると、誰もが突き当たる壁の一つです。

今回はアプリケーションアーキテクチャを学ぶ最初の一歩として、「MVC」や「3 層アーキテクチャ」などの、基本的な用語の意味や関係性を整理します。

発表者が過去に書いた以下の記事を中心に、+α の内容を加えた発表になります。

・「ビジネスロジック」とは何か、どう実装するのか (いいね1700+)
https://qiita.com/os1ma/items/25725edfe3c2af93d735
・MVC、3 層アーキテクチャから設計を学び始めるための基礎知識 (いいね400+)
https://qiita.com/os1ma/items/7a229585ebdd8b7d86c2

Transcript

1. 改めて整理するアプリケーション設計の基本
   

   View Slide

2. 自己紹介
   ● 名前：大嶋勇樹（Twitter：@oshima_123）
   ○ 最近はよく「しま」と呼ばれています
   ● キャリア
   ○ 都内の某 IT 企業 -> フリーランスエンジニア -> 会社設立
   ○ “ ”
   現在は 実務につき始めたエンジニアのスキルアップをサポート
   ○ 研修・勉強会の開催・Udemy 講座の作成など
   ● 関連分野で過去に執筆した記事
   ○ 「ビジネスロジック」とは何か、どう実装するのか（いいね 1700+）
   ○ MVC、3 層アーキテクチャから設計を学び始めるための基礎知識（いいね 400+）
   

   View Slide

3. Udemy 講座の紹介
   Linuxとネットワークの基礎から学ぶDocker入門
   Linux とネットワークの基礎知識から Docker を使った開発環境構築まで、
   手を動かしながら学習する講座
   JavaScriptで学ぶWebアプリ開発の必須知識
   〜Node.js・Web API・Ajax・async/await〜
   「なんとなく」Web アプリ開発に入門で壁になる、Web アプリの仕組みと
   JavaScript の重要知識を、実際にコードを書きながら学習する講座
   リバーシで学ぶアプリケーション設計入門
   〜仕様の整理からTypeScriptでの実装まで〜
   「MVC」「3 層アーキテクチャ」「サービスクラス」「ドメインモデル」など
   アプリケーション設計の基本を学ぶ講座
   今日の発表は、こちらからも抜粋
   先日リリース
   

   View Slide

4. 改めて整理するアプリケーション設計の基本
   

   View Slide

5. 背景
   Web アプリ・モバイルアプリなどを
   「なんとなく」作ることができる人はとても増えています
   最近はプログラミングの入門のハードルは
   非常に低くなっています
   

   View Slide

6. しかし...
   ● 実務に入って、「◯◯アーキテクチャ」「ビジネスロジック」「サービス
   クラス」といった単語に遭遇し、何を指しているのか分からず困っている
   ● 1 ファイルに大量のコードが書かれているのを見て、苦しさを感じる
   ● 「ドメイン駆動設計」や「クリーンアーキテクチャ」を学ぼうとしたが、何
   がなんだか分からない
   「アプリケーションアーキテクチャ」という分野の基礎を学び、
   実際にコードを書いていると分かってくることが多い（自分の経験）
   

   View Slide

7. アジェンダ
   ● アプリケーションアーキテクチャとは
   ● 最も基本の「3 層アーキテクチャ」とは
   ● ビジネスロジックとは
   ● 「Controller に全部書く」からのステップアップ
   

   View Slide

8. 今日の発表内容へのご指摘について
   ● 取り扱う分野の特性上、用語の使い方などについてご指摘事項を感じる方も
   いらっしゃると思います
   ● 入門のために説明を簡略化している箇所や、私個人の意見が含まれる箇所が
   多々ありますが、ご了承ください
   ● ご指摘事項は、「Q&A」に投稿していただければ、確認いたします
   ● その他、気になったご指摘事項やご意見は、Twitter に「#StudyCo」という
   ハッシュタグで投稿いただければ、後ほど拝見させていただきます
   

   View Slide

9. アプリケーションアーキテクチャとは
   

   View Slide

10. アーキテクチャとは
    ● 「アーキテクチャ」は、日本語にすると「建築様式」などと訳されます
    ● ソフトウェア開発では、ざっくり言えば「構造」や「構成」のような意味で
    使われます
    ● ソフトウェア開発と関連する範囲では、以下のように様々な分野があります
    ○ コンピュータアーキテクチャ (CPU アーキテクチャ)
    ○ アプリケーションアーキテクチャ
    ○ インテグレーションアーキテクチャ
    ○ インフラアーキテクチャ
    

    View Slide

11. アプリケーションアーキテクチャ
    ● 「アプリケーションアーキテクチャ」は、かなり曖昧な言葉ですが、
    「開発するアプリケーションの構造のこと」だと思ってください
    フロントエンド サーバサイド データベース
    今日のテーマはこちら
    広い範囲では、ある目的で開発する要素全体の構成が論点です
    狭い範囲では、独立して動作する 1 要素の内部の構成が論点です
    （例）サーバサイドのコードをどんな構造にするか
    

    View Slide

12. インテグレーションアーキテクチャ
    ● 「インテグレーションアーキテクチャ」というのは、システム間の連携を
    どのように実現するかという分野です
    フロントエンド サーバサイド データベース
    他システム
    

    View Slide

13. インフラアーキテクチャ
    ● 「インフラアーキテクチャ」というのは、サーバやネットワークの構成を
    どうするか、といった分野です
    ● 例えば、どんなサーバ構成にするのか、クラウドで動かすのか、コンテナに
    するのか、サーバレスにするのか、といった観点があります
    このように、Web アプリケーションを開発するだけでも、
    様々な観点のアーキテクチャがあります
    

    View Slide

14. 今日のテーマ
    ● ここからは、アプリケーションアーキテクチャの中でも、まとまって
    動作するコードの構成をどのように整理するかがテーマです
    ● この分野には、以下のようなキーワードがあります
    ○ MVC、MVVM、MVP、...
    ○ トランザクションスクリプト、ドメインモデル、...
    ○ リポジトリ、アクティブレコード、...
    ○ 3 層アーキテクチャ、レイヤードアーキテクチャ、クリーンアーキテクチャ、...
    フロントエンド サーバサイド データベース
    この中をどのように整理するか
    

    View Slide

15. 最も基本の「3 層アーキテクチャ」とは
    

    View Slide

16. 「3 層アーキテクチャ」とは
    ● 3 層アーキテクチャと言われて想像するものは、(私は) 2 種類あります
    アプリケーション内部の 3 層アーキテクチャ
    Web アプリケーションの 3 層構造
    

    View Slide

17. Web アプリケーションの 3 層構造
    ● Web アプリケーションの基本構成は、Web サーバ・アプリケーション・DB
    の 3 つから成り立つ 3 層構造です
    ● この 3 層構造を「3 層アーキテクチャ」と呼ぶことがあります
    Web
    サーバ
    アプリケーション DB
    固定の HTML・CSS・JS などを返し、
    プログラムによる処理が必要な場合は
    アプリケーションに依頼する
    プログラムで
    HTML や JSON などを
    生成して返す
    

    View Slide

18. アプリケーション内部の 3 層アーキテクチャ
    ● 一方で、アプリケーションの内部を 3 層に分けて整理することがあります
    ● これも「3 層アーキテクチャ」と呼ぶことがあります
    Web
    サーバ
    アプリケーション DB
    プレゼン
    テーション層
    ビジネス
    ロジック層
    データ
    アクセス層
    内部のコードを層に分けて整理
    ここからは、アプリケーションの内部を 3 層に分けた、
    こちらの 3 層アーキテクチャについて話します
    

    View Slide

19. 3 層アーキテクチャの役割分担
    ● ここで、3 層アーキテクチャの各層の役割を整理してみます
    プレゼン
    テーション層
    ビジネス
    ロジック層
    データ
    アクセス層
    アプリケーションの利用者
    （人間や別のプログラム）
    とやりとりする
    DB やファイルなどの
    データの保存先
    とやりとりする
    「ビジネスロジック」
    を実装する
    「ビジネスロジック」の意味はあとでしっかり説明するので、まずは
    プレゼンテーション層とデータアクセス層の役割をおさえましょう
    

    View Slide

20. データアクセス層
    ● データアクセス層の役割は、ファイルや DB などのデータの保存先に対して
    データを読み書きすることです
    ● ビジネスロジックをデータアクセスと切り離すというのは、保存先がファイ
    ルだろうと、RDB だろうと、その他の DB だろうと、ビジネスロジックはそ
    れを気にかけないように記述するということです
    ● よく見かける実装方式は、データベースのテーブルと対応した読み書き用の
    クラスを作成する「Table Data Gateway (DAO)」パターンです
    データ
    アクセス層
    ビジネス
    ロジック層
    プレゼン
    テーション層
    

    View Slide

21. プレゼンテーション層と MVC
    ● プレゼンテーション層のアーキテクチャとして有名なのが「MVC」です
    ● MVC と 3 層アーキテクチャを対応させると、以下の図のようになります
    プレゼンテーション層 ビジネスロジック層 データアクセス層
    Controller
    View
    Model
    入力の受け付け
    UI
    データ
    アクセス層
    ビジネス
    ロジック層
    プレゼン
    テーション層
    

    View Slide

22. プレゼンテーション層
    ● プレゼンテーション層は、そのアプリケーションの利用者（人間や別のプロ
    グラム）とやりとりする層です
    ● 例えば、以下のようなものがプレゼンテーション層に属します
    ○ HTML を返す Web アプリケーションの場合
    ➢ リクエストの受け取り (Controller ) や UI (View)
    ○ JSON などを返す Web アプリケーション (Web API) の場合
    ➢ API の出入り口 (Controller) や・リクエストやレスポンスの型
    ○ CLI アプリケーションの場合
    ➢ ユーザからの入力受付・処理結果の出力
    データ
    アクセス層
    ビジネス
    ロジック層
    プレゼン
    テーション層
    

    View Slide

23. （補足）プレゼンテーション層とフロントエンドの違い
    Web
    サーバ
    アプリケーション DB
    プレゼン
    テーション層
    ビジネス
    ロジック層
    データ
    アクセス層
    内部のコードを層に分けて整理
    サーバサイド
    （サーバ上で処理される）
    HTML
    CSS
    JS
    ※ Rails で ERB、Laravel で Blade、Spring で Thymeleaf などを使い、サーバサイドで
    　 HTML を生成する方式の場合は、プレゼンテーション層はフロントエンドになります
    フロントエンド
    （ブラウザなど、ユーザの手元で処理される）
    

    View Slide

24. 改めて整理すると...
    ● 3 層アーキテクチャでは、以下のような分担で層分けします
    プレゼン
    テーション層
    ビジネス
    ロジック層
    データ
    アクセス層
    アプリケーションの利用者
    （人間や別のプログラム）
    とやりとりする
    DB やファイルなどの
    データの保存先
    とやりとりする
    「ビジネスロジック」
    を実装する
    

    View Slide

25. 典型的な 3 層アーキテクチャの構成例
    ● 以下のような構成が、3 層アーキテクチャ (+ MVC) の典型例です
    ※ クラス名の付け方は色々あります
    プレゼンテーション層 ビジネスロジック層 データアクセス層
    Controller
    View Output (DTO)
    Gateway
    (DAO)
    Record (Entity)
    Service
    利用者とやりとり
    UI Service の戻り値
    DB とやりとり
    データの入れ物
    ビジネスロジック
    

    View Slide

26. ビジネスロジックとは
    

    View Slide

27. アプリケーションの役割を 3 層で整理
    プレゼン
    テーション層
    ビジネス
    ロジック層
    データ
    アクセス層
    アプリケーションの利用者
    （人間や別のプログラム）
    とやりとりする
    DB やファイルなどの
    データの保存先
    とやりとりする
    「システムのコア」や
    「システムの目的の処理を
    するところ」と言われる
    まずは、「とっかかりとして」プレゼンテーションでも
    データアクセスでもない部分がビジネスロジックと考えてみましょう
    この説明は、
    意味を分かってからはしっくりくるが、
    最初はあまりにも難しい...
    

    View Slide

28. 例えば、リバーシを考えてみましょう
    ● リバーシで石を打つときの処理は、例えばこんな流れになります
    ○ プレイヤーの入力（石をどこに打つか）を受け付ける
    ○ データアクセス層を使って、盤面の状態を取得する
    ○ 盤面に置けるかチェック
    ○ 石を置く
    ○ ひっくり返す
    ○ データアクセス層を使って、盤面の状態を保存する
    ○ 画面に新しい状態の盤面を表示する
    これがビジネスロジックの例であり、
    ビジネスロジック層に書くべきコードです
    ここがビジネスロジック！！
    見ての通り、
    ● 利用者とのやりとりの方法
    ● 保存先の DB の種類
    などは関係ない
    

    View Slide

29. これはビジネスロジック？（1/4）
    ● 見た目を整えるために日付時刻の形式変換するのはビジネスロジック？
    ○ 「2004-04-01T12:00+09:00」=>「2004年4月1日12時00分」
    ● 見た目を整えるための日付時刻の形式変換は、プレゼンテーション層の役割
    であって、「ビジネスロジックではない」と判断されることが多いです
    ● ただし、「日付時刻形式変換アプリケーション」であれば、この処理は
    「ビジネスロジックである」と言えます
    同じ処理であっても、アプリケーションの性質次第で
    ビジネスロジックと言える場合と言えない場合があります
    

    View Slide

30. これはビジネスロジック？（2/4）
    ● リクエストの形式チェックはビジネスロジック？
    ○ リクエストの必須パラメータは足りているか
    ○ リクエストのデータサイズは決められた範囲内か
    ● 以下のような理由で、これらは「プレゼンテーション層」でチェックすべき
    内容だと考えています
    ○ 利用者とのインタフェースでの約束事に関するチェックであること
    ○ 不正なデータはできるだけ早く検知し、以後のプログラムに進ませないようにしたいこと
    ○ DB とのやりとりが不要なため、簡単に実装できること
    

    View Slide

31. これはビジネスロジック？（3/4）
    ● リクエストの形式より少しだけ複雑な条件チェックはビジネスロジック？
    ○ SNS で、自分には「イイね」できないようにする
    ○ TODO 管理アプリで、過去日の TODO は登録できないようにする
    ● 私は以下の 2 つの理由でこれは「ビジネスロジックである」と考えています
    ○ プレゼンテーション層は見た目などの UI に直接関わることだけを知っているべきであり、こ
    のような知識を持つべきではないこと
    ○ ユーザインタフェースが GUI か API か CLI かといった、プレゼンテーション層の違いによら
    ず、共通したチェックであると想定されること
    

    View Slide

32. これはビジネスロジック？（4/4）
    ● DB のデータとの整合性チェックはビジネスロジック？
    ○ リバーシで、現在の盤面を踏まえ、指定された場所に石を置くことができるか判定する
    ○ EC サイトで購入リクエストした商品が購入可能なものか判定する
    ● これは「まさにビジネスロジックである」と考えています
    ● リバーシの場合、石をひっくり返す計算処理もまさにビジネスロジックです
    アプリケーションが従うべきルールのチェックであったり、
    ルールを適用する計算処理が、まさにビジネスロジックの中心です
    

    View Slide

33. ドメインロジックとユースケース
    ● ビジネスロジック層の処理は、「ドメインロジック」と「ユースケース」の2
    種類に分類すると整理しやすいです
    ● リバーシで石を打つときの処理の流れの例だと...
    ○ データアクセス層を使って、盤面の状態を取得する
    ○ 盤面に置けるかチェック
    ○ 石を置く
    ○ ひっくり返す
    ○ データアクセス層を使って、盤面の状態を保存する
    「システム都合ではない、コアなルール」
    ・ドメインロジック
    ・エンタープライズビジネスルール
    と呼ばれることも
    「処理の流れを実現すること」
    ・ユースケース
    ・アプリケーションビジネスルール
    と呼ばれることも
    

    View Slide

34. ドメインロジックの例
    ● リバーシ
    ○ 盤面に置けるかチェック
    ○ はさまれた石をひっくり返す
    ● ホテルの予約
    ○ 指定された部屋に、宿泊できる人数の予約かチェック
    ○ 何日前のキャンセルなので、キャンセル料はいくらか算出
    システムなしで、現実世界で同じことをやろうとしたときにも
    登場するルールは、ドメインロジックの分かりやすい例です
    電話予約や対面での予約など、
    システムなしで人間が対応するときにも
    登場するルール
    

    View Slide

35. ビジネスロジックの実装方式
    

    View Slide

36. ここから、ビジネスロジックの実装について見ていきます
    ● リバーシで石を打つときの処理の流れの例だと...
    ○ プレイヤーの入力（石をどこに打つか）を受け付ける
    ○ データアクセス層を使って、盤面の状態を取得する
    ○ 盤面に置けるかチェック
    ○ 石を置く
    ○ ひっくり返す
    ○ データアクセス層を使って、盤面の状態を保存する
    ○ 画面に新しい状態の盤面を表示する
    ビジネスロジックの実装方法は、「トランザクションスクリプト」と
    「ドメインモデル」の 2 種類があります
    ビジネスロジックはここ
    単純化すると...
    ・データの取得の呼び出し
    ・チェックや計算処理
    ・データの保存の呼び出し
    

    View Slide

37. トランザクションスクリプトとドメインモデル
    トランザクションスクリプト
    パターン
    ドメインモデル
    パターン
    ビジネスロジック層
    DTO
    (Model…?)
    Service
    データの入れ物
    ドメインロジック
    ユースケース
    ビジネスロジック層
    Domain Model
    Service
    データの入れ物
    ドメインロジック
    ユースケース
    ・データの取得の呼び出し
    ・チェックや計算処理
    ・データの保存の呼び出し
    の全てを Service に実装
    ドメインロジック
    （チェックや計算処理）を
    データの入れ物となる
    クラスに一緒に持たせる
    

    View Slide

38. トランザクションスクリプトとドメインモデル
    トランザクションスクリプト
    パターン
    ドメインモデル
    パターン
    概要
    ● データの入れ物と処理を分離する
    ● 手続き型プログラミング
    ● Service がドメインロジックと
    ユースケースを担当
    メリット
    ● 学習コストが低い
    デメリット
    ● Service クラスが肥大化しやすい
    ● 同じロジックが Service クラス間
    に分散しやすく、変更に弱い
    概要
    ● データの入れ物に処理も持たせる
    ● オブジェクト指向プログラミング
    ● Model はドメインロジックを担当
    ● Service はユースケースを担当
    メリット
    ● Service クラスが肥大化しにくい
    ● 同じロジックが分散しにくく、変
    更に強くなりやすい
    デメリット
    ● 学習コストが高い
    

    View Slide

39. ドメインモデルを使う構成例
    ● 例えば、アプリケーション層とドメイン層を分離した 4 層の構成があります
    ● 以下のような構成を「レイヤードアーキテクチャ」と呼びます
    プレゼンテーション層 アプリケーション層 データアクセス層
    （インフラ層）
    Controller
    View
    利用者とやりとり
    UI
    Service
    (UseCase)
    ユースケース
    Record
    データの入れ物
    ドメイン層
    Domain Model
    ドメインロジック
    Output (DTO)
    Service の戻り値
    Gateway
    (DAO)
    DB とやりとり
    ※ 実際には、次の Repository パターンも使う例をレイヤードアーキテクチャと呼ぶことが多いと思われます
    

    View Slide

40. Repository パターン
    ● 以下は、DB のテーブル都合ではなく、ドメインモデルの都合でデータを
    読み書きする「Repository パターン」を導入した構成です
    プレゼンテーション層 アプリケーション層 データアクセス層
    （インフラ層）
    Controller
    View
    利用者とやりとり
    UI
    Service
    (UseCase)
    ユースケース
    Record
    データの入れ物
    ドメイン層
    Domain Model
    ドメインロジック
    Output (DTO)
    Service の戻り値
    Gateway
    (DAO)
    DB とやりとり
    ※ Repository の実装に Table Data Gateway を使うのはあくまで一例で、実装はどんな方法でも構いません
    Repository
    

    View Slide

41. アプリケーション設計の観点
    ● 層分け：3 層・レイヤード・ヘキサゴナル・オニオン
    ● プレゼンテーション：MVC・MVVM
    ● ビジネスロジック：トランザクションスクリプト・ドメインモデル
    ● データアクセス：Table Data Gateway・Repository
    ポイントは、「層分け」と「各層の実装方式」の観点があり、
    様々な組み合わせがありえるということです
    

    View Slide

42. アーキテクチャの組み合わせ例
    ● レイヤード + MVC + ドメインモデル + Repository
    ● Repository の内部実装は Table Data Gateway
    プレゼンテーション層 アプリケーション層 データアクセス層
    （インフラ層）
    Controller
    View
    利用者とやりとり
    UI
    Service
    (UseCase)
    ユースケース
    Record
    データの入れ物
    ドメイン層
    Domain Model
    ドメインロジック
    Output (DTO)
    Service の戻り値
    Gateway
    (DAO)
    DB とやりとり
    Repository
    

    View Slide

43. アプリケーション設計の学習のポイント
    ● アプリケーション設計には、以下のように異なる観点があります
    ○ どのように層を分けるか
    ■ 3 層・レイヤード・ヘキサゴナル・オニオン...
    ○ 各層をどのように実装するか
    ■ MVC・MVVM・MVP...
    ■ トランザクションスクリプト・ドメインモデル...
    ■ Table Data Gateway・Repository…
    ○ ドメインモデルをどう設計・実装するか
    アプリケーション設計に関する書籍を読んだりするときは、
    どの観点の話なのか注意してみると理解しやすくなることがあります
    

    View Slide

44. 「Controller に全部書く」からのステップアップ
    例 1
    

    View Slide

45. 例 1
    ● ノンフレームワーク・Express などの軽量なフレームワークで、Controller に
    SQL まで書かれている場合...
    プレゼンテーション層 ビジネスロジック層 データアクセス層
    Controller
    View Record
    利用者とやりとり
    UI
    ユースケース
    ドメインロジック
    データの入れ物
    DB とやりとり
    

    View Slide

46. データアクセスの分離
    ● 例えば、まずデータアクセス用のクラスを設けてみます
    プレゼンテーション層 ビジネスロジック層 データアクセス層
    Controller
    View Record
    利用者とやりとり
    UI
    ユースケース
    ドメインロジック
    データの入れ物
    Gateway
    DB とやりとり
    

    View Slide

47. プレゼンテーションとビジネスロジックの分離
    ● Service を設けて、ビジネスロジック（ユースケースとドメインロジック）を
    移動します
    プレゼンテーション層 ビジネスロジック層 データアクセス層
    Controller
    View Record
    利用者とやりとり
    UI データの入れ物
    Gateway
    DB とやりとり
    Service
    ユースケース
    ドメインロジック
    

    View Slide

48. ドメインロジックの分離
    ● ドメインロジックは、Domain Model に持たせます
    （さらに、ドメイン層を分けたり、Repository パターンを導入したり...）
    プレゼンテーション層 ビジネスロジック層 データアクセス層
    Controller
    View Record
    利用者とやりとり
    UI データの入れ物
    Gateway
    DB とやりとり
    Service
    ユースケース
    Domain Model
    ドメインロジック
    

    View Slide

49. ポイント
    ● ポイントは、クラスごとの「役割分担」です
    ● 他にも、「表示用の変換は Presenter」といった分担も考えられます
    プレゼンテーション層 ビジネスロジック層 データアクセス層
    Controller
    View Record
    利用者とやりとり
    UI データの入れ物
    Gateway
    DB とやりとり
    Service
    ユースケース
    Domain Model
    ドメインロジック
    

    View Slide

50. 「Controller に全部書く」からのステップアップ
    例 2
    

    View Slide

51. 例 2
    ● 今度は Rails や Laravel などで ActiveRecord 系 OR マッパーを使う例です
    ● よくある苦しくなりやすい構成は、以下のような役割分担です
    プレゼンテーション層 ビジネスロジック層 データアクセス層
    Controller
    View Model
    利用者とやりとり
    UI
    ユースケース
    ドメインロジック
    DB とやりとり
    データの入れ物
    

    View Slide

52. 本来のアクティブレコードパターン
    ● アクティブレコードパターンは、「DB のレコードと対応するクラスを作成
    し、データアクセスのメソッドと、ドメインロジックを持たせる」ものです
    ● つまり、アクティブレコードのモデルの役割は、本来は以下の 3 つです
    ○ データベースのレコードと対応するデータを持つ
    ○ データアクセスのメソッドを持つ
    ○ ドメインロジックを持つ
    アクティブレコード系 OR マッパーを使うと、ドメインロジックが DB
    に強く依存する代わりに、実装量が非常に少なくなります
    

    View Slide

53. MVC + 本来のアクティブレコードの構成
    ● MVC とアクティブレコードパターンを組み合わせる場合は、以下のような
    構成になるのが本来的です
    プレゼンテーション層 ビジネスロジック層 データアクセス層
    Controller
    View
    Model
    (ActiveRecord)
    利用者とやりとり
    UI
    ユースケース
    ドメインロジック
    DB とやりとり
    データの入れ物
    

    View Slide

54. ユースケースの分離
    ● もし Controller からユースケースを分離したい場合は、Service ( または
    UseCase) クラスを設ける手法を使うことができます
    プレゼンテーション層 ビジネスロジック層 データアクセス層
    Controller
    View
    Model
    (ActiveRecord)
    利用者とやりとり
    UI
    ドメインロジック
    DB とやりとり
    データの入れ物
    Service
    (UseCase)
    ユースケース
    

    View Slide

55. ActiveRecord による Repository の実装
    ● ActiveRecord や Eloquent で Repository の実装も可能ですが、ActiveRecord
    のメリットは非常に弱くなります（あまりおすすめしません）
    プレゼンテーション層 ビジネスロジック層 データアクセス層
    Controller
    View ドメインモデル
    利用者とやりとり
    UI
    ドメインロジック
    Service
    (UseCase)
    ユースケース
    ActiveRecord
    DB とやりとり
    データの入れ物
    Repository
    呼び出し
    ActiveRecord とは関係ない
    ドメインロジックのためのモデル
    

    View Slide

56. フレームワークなどの特性を活かす
    ● MVC + ActiveRecord 系 OR マッパーで、少ないコードで実装できることが魅
    力のフレームワークであれば、その特性を活かした構成が良いと思います
    プレゼンテーション層 ビジネスロジック層 データアクセス層
    Controller
    View
    Model
    (ActiveRecord)
    利用者とやりとり
    UI
    ユースケース
    ドメインロジック
    DB とやりとり
    データの入れ物
    

    View Slide

57. 設計とプログラミング言語・フレームワーク
    ● 様々な言語・フレームワークで使える基本をおさえつつ...
    「言語やフレームワークに適した設計を採用すること」
    「設計手法に適した言語やフレームワークを採用すること」
    が重要だと思います
    設計手法にも「常に正解」なものがあるわけではないので、
    使っている技術や状況と、うまく適合させましょう
    

    View Slide

58. 参考文献
    ● 『エンタープライズアプリケーションアーキテクチャパターン』
    ○ マーチン・ファウラー (著), 株式会社テクノロジックアート (翻訳), 長瀬嘉秀 (翻訳, 監修), 2005, 翔泳社
    ● 『エリック・エヴァンスのドメイン駆動設計』
    ○ エリック・エヴァンス (著), 今関 剛 (監修), 和智 右桂 (翻訳), 牧野 祐子 (翻訳), 2011, 翔泳社
    ● 『実践ドメイン駆動設計』
    ○ ヴォーン・ヴァーノン (著), 髙木 正弘 (翻訳), 2015, 翔泳社
    ● 『Clean Architecture 達人に学ぶソフトウェアの構造と設計』
    ○ Robert C.Martin (著), 角 征典 (翻訳), 高木 正弘 (翻訳), 2018, KADOKAWA
    ● 　
    『．ＮＥＴのエンタープライズアプリケーションアーキテクチャ 第２版』
    ○ Dino Esposito (著), Andrea Saltarello (著), 日本マイクロソフト (監訳), クイープ (翻訳), 2015, 日経BP
    ● 『現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法』
    ○ 増田 亨 (著), 2017, 技術評論社
    

    View Slide

59. 改めて整理するアプリケーション設計の基本
    

    View Slide

60. 宣伝
    ● つい先日、Udemy で今日のテーマの分野の講座をリリースしました
    リバーシで学ぶアプリケーション設計入門
    今日のテーマの分野を、具体的な実装含め解説した講座です
    アプリケーション設計に大きく関わる仕様の整理から、
    TypeScript での実装例まで解説しています
    エラーの解決や疑問点なども、できるだけサポートします
    クーポン付き URL を共有させていただくので、
    ご興味ある方は手にとっていただけると嬉しいです
    ※ Speaker Deck の説明欄にも貼っています
    

    View Slide

61. Appendix
    

    View Slide

62. ドメイン層を中心にした構成例（1/2）
    ● 依存性逆転の原則を適用することで、ドメイン層を中心にできます
    プレゼンテーション層 アプリケーション層 データアクセス層
    （インフラ層）
    Controller
    View
    利用者とやりとり
    UI
    Service
    (UseCase)
    ユースケース
    ドメイン層
    Domain Model
    ドメインロジック
    Output (DTO)
    Service の戻り値
    Repository
    DB とやりとり
    << interface >>
    Repository
    実装クラス
    

    View Slide

63. ドメイン層を中心にした構成例（2/2）
    ● 円を書いてみると、依存が内側だけに向かっていることが分かります
    プレゼンテーション層 アプリケーション層 データアクセス層
    （インフラ層）
    Controller
    View
    利用者とやりとり
    UI
    Service
    (UseCase)
    ユースケース
    ドメイン層
    Domain Model
    ドメインロジック
    Output (DTO)
    Service の戻り値
    Repository
    DB とやりとり
    << interface >>
    Repository
    

    View Slide