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

●発表のアーカイブ動画はこちら：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. 改めて整理するアプリケーション設計の基本
2. 自己紹介 • 名前：大嶋勇樹（Twitter：@oshima_123） ◦ 最近はよく「しま」と呼ばれています • キャリア ◦ 都内の某 IT 企業 -> フリーランスエンジニア -> 会社設立 ◦ “ ” 現在は 実務につき始めたエンジニアのスキルアップをサポート ◦ 研修・勉強会の開催・Udemy 講座の作成など • 関連分野で過去に執筆した記事 ◦ 「ビジネスロジック」とは何か、どう実装するのか（いいね 1700+） ◦ MVC、3 層アーキテクチャから設計を学び始めるための基礎知識（いいね 400+）
3. Udemy 講座の紹介 Linuxとネットワークの基礎から学ぶDocker入門 Linux とネットワークの基礎知識から Docker を使った開発環境構築まで、 手を動かしながら学習する講座 JavaScriptで学ぶWebアプリ開発の必須知識 〜Node.js・Web API・Ajax・async/await〜 「なんとなく」Web アプリ開発に入門で壁になる、Web アプリの仕組みと JavaScript の重要知識を、実際にコードを書きながら学習する講座 リバーシで学ぶアプリケーション設計入門 〜仕様の整理からTypeScriptでの実装まで〜 「MVC」「3 層アーキテクチャ」「サービスクラス」「ドメインモデル」など アプリケーション設計の基本を学ぶ講座 今日の発表は、こちらからも抜粋 先日リリース
4. 改めて整理するアプリケーション設計の基本
5. 背景 Web アプリ・モバイルアプリなどを 「なんとなく」作ることができる人はとても増えています 最近はプログラミングの入門のハードルは 非常に低くなっています
6. しかし... • 実務に入って、「◯◯アーキテクチャ」「ビジネスロジック」「サービス クラス」といった単語に遭遇し、何を指しているのか分からず困っている • 1 ファイルに大量のコードが書かれているのを見て、苦しさを感じる • 「ドメイン駆動設計」や「クリーンアーキテクチャ」を学ぼうとしたが、何 がなんだか分からない 「アプリケーションアーキテクチャ」という分野の基礎を学び、 実際にコードを書いていると分かってくることが多い（自分の経験）
7. アジェンダ • アプリケーションアーキテクチャとは • 最も基本の「3 層アーキテクチャ」とは • ビジネスロジックとは • 「Controller に全部書く」からのステップアップ
8. 今日の発表内容へのご指摘について • 取り扱う分野の特性上、用語の使い方などについてご指摘事項を感じる方も いらっしゃると思います • 入門のために説明を簡略化している箇所や、私個人の意見が含まれる箇所が 多々ありますが、ご了承ください • ご指摘事項は、「Q&A」に投稿していただければ、確認いたします • その他、気になったご指摘事項やご意見は、Twitter に「#StudyCo」という ハッシュタグで投稿いただければ、後ほど拝見させていただきます
9. アプリケーションアーキテクチャとは
10. アーキテクチャとは • 「アーキテクチャ」は、日本語にすると「建築様式」などと訳されます • ソフトウェア開発では、ざっくり言えば「構造」や「構成」のような意味で 使われます • ソフトウェア開発と関連する範囲では、以下のように様々な分野があります ◦ コンピュータアーキテクチャ (CPU アーキテクチャ) ◦ アプリケーションアーキテクチャ ◦ インテグレーションアーキテクチャ ◦ インフラアーキテクチャ
11. アプリケーションアーキテクチャ • 「アプリケーションアーキテクチャ」は、かなり曖昧な言葉ですが、 「開発するアプリケーションの構造のこと」だと思ってください フロントエンド サーバサイド データベース 今日のテーマはこちら 広い範囲では、ある目的で開発する要素全体の構成が論点です 狭い範囲では、独立して動作する 1 要素の内部の構成が論点です （例）サーバサイドのコードをどんな構造にするか
12. インテグレーションアーキテクチャ • 「インテグレーションアーキテクチャ」というのは、システム間の連携を どのように実現するかという分野です フロントエンド サーバサイド データベース 他システム
13. インフラアーキテクチャ • 「インフラアーキテクチャ」というのは、サーバやネットワークの構成を どうするか、といった分野です • 例えば、どんなサーバ構成にするのか、クラウドで動かすのか、コンテナに するのか、サーバレスにするのか、といった観点があります このように、Web アプリケーションを開発するだけでも、 様々な観点のアーキテクチャがあります
14. 今日のテーマ • ここからは、アプリケーションアーキテクチャの中でも、まとまって 動作するコードの構成をどのように整理するかがテーマです • この分野には、以下のようなキーワードがあります ◦ MVC、MVVM、MVP、... ◦ トランザクションスクリプト、ドメインモデル、... ◦ リポジトリ、アクティブレコード、... ◦ 3 層アーキテクチャ、レイヤードアーキテクチャ、クリーンアーキテクチャ、... フロントエンド サーバサイド データベース この中をどのように整理するか
15. 最も基本の「3 層アーキテクチャ」とは
16. 「3 層アーキテクチャ」とは • 3 層アーキテクチャと言われて想像するものは、(私は) 2 種類あります アプリケーション内部の 3 層アーキテクチャ Web アプリケーションの 3 層構造
17. Web アプリケーションの 3 層構造 • Web アプリケーションの基本構成は、Web サーバ・アプリケーション・DB の 3 つから成り立つ 3 層構造です • この 3 層構造を「3 層アーキテクチャ」と呼ぶことがあります Web サーバ アプリケーション DB 固定の HTML・CSS・JS などを返し、 プログラムによる処理が必要な場合は アプリケーションに依頼する プログラムで HTML や JSON などを 生成して返す
18. アプリケーション内部の 3 層アーキテクチャ • 一方で、アプリケーションの内部を 3 層に分けて整理することがあります • これも「3 層アーキテクチャ」と呼ぶことがあります Web サーバ アプリケーション DB プレゼン テーション層 ビジネス ロジック層 データ アクセス層 内部のコードを層に分けて整理 ここからは、アプリケーションの内部を 3 層に分けた、 こちらの 3 層アーキテクチャについて話します
19. 3 層アーキテクチャの役割分担 • ここで、3 層アーキテクチャの各層の役割を整理してみます プレゼン テーション層 ビジネス ロジック層 データ アクセス層 アプリケーションの利用者 （人間や別のプログラム） とやりとりする DB やファイルなどの データの保存先 とやりとりする 「ビジネスロジック」 を実装する 「ビジネスロジック」の意味はあとでしっかり説明するので、まずは プレゼンテーション層とデータアクセス層の役割をおさえましょう
20. データアクセス層 • データアクセス層の役割は、ファイルや DB などのデータの保存先に対して データを読み書きすることです • ビジネスロジックをデータアクセスと切り離すというのは、保存先がファイ ルだろうと、RDB だろうと、その他の DB だろうと、ビジネスロジックはそ れを気にかけないように記述するということです • よく見かける実装方式は、データベースのテーブルと対応した読み書き用の クラスを作成する「Table Data Gateway (DAO)」パターンです データ アクセス層 ビジネス ロジック層 プレゼン テーション層
21. プレゼンテーション層と MVC • プレゼンテーション層のアーキテクチャとして有名なのが「MVC」です • MVC と 3 層アーキテクチャを対応させると、以下の図のようになります プレゼンテーション層 ビジネスロジック層 データアクセス層 Controller View Model 入力の受け付け UI データ アクセス層 ビジネス ロジック層 プレゼン テーション層
22. プレゼンテーション層 • プレゼンテーション層は、そのアプリケーションの利用者（人間や別のプロ グラム）とやりとりする層です • 例えば、以下のようなものがプレゼンテーション層に属します ◦ HTML を返す Web アプリケーションの場合 ➢ リクエストの受け取り (Controller ) や UI (View) ◦ JSON などを返す Web アプリケーション (Web API) の場合 ➢ API の出入り口 (Controller) や・リクエストやレスポンスの型 ◦ CLI アプリケーションの場合 ➢ ユーザからの入力受付・処理結果の出力 データ アクセス層 ビジネス ロジック層 プレゼン テーション層
23. （補足）プレゼンテーション層とフロントエンドの違い Web サーバ アプリケーション DB プレゼン テーション層 ビジネス ロジック層 データ アクセス層 内部のコードを層に分けて整理 サーバサイド （サーバ上で処理される） HTML CSS JS ※ Rails で ERB、Laravel で Blade、Spring で Thymeleaf などを使い、サーバサイドで 　 HTML を生成する方式の場合は、プレゼンテーション層はフロントエンドになります フロントエンド （ブラウザなど、ユーザの手元で処理される）
24. 改めて整理すると... • 3 層アーキテクチャでは、以下のような分担で層分けします プレゼン テーション層 ビジネス ロジック層 データ アクセス層 アプリケーションの利用者 （人間や別のプログラム） とやりとりする DB やファイルなどの データの保存先 とやりとりする 「ビジネスロジック」 を実装する
25. 典型的な 3 層アーキテクチャの構成例 • 以下のような構成が、3 層アーキテクチャ (+ MVC) の典型例です ※ クラス名の付け方は色々あります プレゼンテーション層 ビジネスロジック層 データアクセス層 Controller View Output (DTO) Gateway (DAO) Record (Entity) Service 利用者とやりとり UI Service の戻り値 DB とやりとり データの入れ物 ビジネスロジック
26. ビジネスロジックとは
27. アプリケーションの役割を 3 層で整理 プレゼン テーション層 ビジネス ロジック層 データ アクセス層 アプリケーションの利用者 （人間や別のプログラム） とやりとりする DB やファイルなどの データの保存先 とやりとりする 「システムのコア」や 「システムの目的の処理を するところ」と言われる まずは、「とっかかりとして」プレゼンテーションでも データアクセスでもない部分がビジネスロジックと考えてみましょう この説明は、 意味を分かってからはしっくりくるが、 最初はあまりにも難しい...
28. 例えば、リバーシを考えてみましょう • リバーシで石を打つときの処理は、例えばこんな流れになります ◦ プレイヤーの入力（石をどこに打つか）を受け付ける ◦ データアクセス層を使って、盤面の状態を取得する ◦ 盤面に置けるかチェック ◦ 石を置く ◦ ひっくり返す ◦ データアクセス層を使って、盤面の状態を保存する ◦ 画面に新しい状態の盤面を表示する これがビジネスロジックの例であり、 ビジネスロジック層に書くべきコードです ここがビジネスロジック！！ 見ての通り、 • 利用者とのやりとりの方法 • 保存先の DB の種類 などは関係ない
29. これはビジネスロジック？（1/4） • 見た目を整えるために日付時刻の形式変換するのはビジネスロジック？ ◦ 「2004-04-01T12:00+09:00」=>「2004年4月1日12時00分」 • 見た目を整えるための日付時刻の形式変換は、プレゼンテーション層の役割 であって、「ビジネスロジックではない」と判断されることが多いです • ただし、「日付時刻形式変換アプリケーション」であれば、この処理は 「ビジネスロジックである」と言えます 同じ処理であっても、アプリケーションの性質次第で ビジネスロジックと言える場合と言えない場合があります
30. これはビジネスロジック？（2/4） • リクエストの形式チェックはビジネスロジック？ ◦ リクエストの必須パラメータは足りているか ◦ リクエストのデータサイズは決められた範囲内か • 以下のような理由で、これらは「プレゼンテーション層」でチェックすべき 内容だと考えています ◦ 利用者とのインタフェースでの約束事に関するチェックであること ◦ 不正なデータはできるだけ早く検知し、以後のプログラムに進ませないようにしたいこと ◦ DB とのやりとりが不要なため、簡単に実装できること
31. これはビジネスロジック？（3/4） • リクエストの形式より少しだけ複雑な条件チェックはビジネスロジック？ ◦ SNS で、自分には「イイね」できないようにする ◦ TODO 管理アプリで、過去日の TODO は登録できないようにする • 私は以下の 2 つの理由でこれは「ビジネスロジックである」と考えています ◦ プレゼンテーション層は見た目などの UI に直接関わることだけを知っているべきであり、こ のような知識を持つべきではないこと ◦ ユーザインタフェースが GUI か API か CLI かといった、プレゼンテーション層の違いによら ず、共通したチェックであると想定されること
32. これはビジネスロジック？（4/4） • DB のデータとの整合性チェックはビジネスロジック？ ◦ リバーシで、現在の盤面を踏まえ、指定された場所に石を置くことができるか判定する ◦ EC サイトで購入リクエストした商品が購入可能なものか判定する • これは「まさにビジネスロジックである」と考えています • リバーシの場合、石をひっくり返す計算処理もまさにビジネスロジックです アプリケーションが従うべきルールのチェックであったり、 ルールを適用する計算処理が、まさにビジネスロジックの中心です
33. ドメインロジックとユースケース • ビジネスロジック層の処理は、「ドメインロジック」と「ユースケース」の2 種類に分類すると整理しやすいです • リバーシで石を打つときの処理の流れの例だと... ◦ データアクセス層を使って、盤面の状態を取得する ◦ 盤面に置けるかチェック ◦ 石を置く ◦ ひっくり返す ◦ データアクセス層を使って、盤面の状態を保存する 「システム都合ではない、コアなルール」 ・ドメインロジック ・エンタープライズビジネスルール と呼ばれることも 「処理の流れを実現すること」 ・ユースケース ・アプリケーションビジネスルール と呼ばれることも
34. ドメインロジックの例 • リバーシ ◦ 盤面に置けるかチェック ◦ はさまれた石をひっくり返す • ホテルの予約 ◦ 指定された部屋に、宿泊できる人数の予約かチェック ◦ 何日前のキャンセルなので、キャンセル料はいくらか算出 システムなしで、現実世界で同じことをやろうとしたときにも 登場するルールは、ドメインロジックの分かりやすい例です 電話予約や対面での予約など、 システムなしで人間が対応するときにも 登場するルール
35. ビジネスロジックの実装方式
36. ここから、ビジネスロジックの実装について見ていきます • リバーシで石を打つときの処理の流れの例だと... ◦ プレイヤーの入力（石をどこに打つか）を受け付ける ◦ データアクセス層を使って、盤面の状態を取得する ◦ 盤面に置けるかチェック ◦ 石を置く ◦ ひっくり返す ◦ データアクセス層を使って、盤面の状態を保存する ◦ 画面に新しい状態の盤面を表示する ビジネスロジックの実装方法は、「トランザクションスクリプト」と 「ドメインモデル」の 2 種類があります ビジネスロジックはここ 単純化すると... ・データの取得の呼び出し ・チェックや計算処理 ・データの保存の呼び出し
37. トランザクションスクリプトとドメインモデル トランザクションスクリプト パターン ドメインモデル パターン ビジネスロジック層 DTO (Model…?) Service データの入れ物 ドメインロジック ユースケース ビジネスロジック層 Domain Model Service データの入れ物 ドメインロジック ユースケース ・データの取得の呼び出し ・チェックや計算処理 ・データの保存の呼び出し の全てを Service に実装 ドメインロジック （チェックや計算処理）を データの入れ物となる クラスに一緒に持たせる
38. トランザクションスクリプトとドメインモデル トランザクションスクリプト パターン ドメインモデル パターン 概要 • データの入れ物と処理を分離する • 手続き型プログラミング • Service がドメインロジックと ユースケースを担当 メリット • 学習コストが低い デメリット • Service クラスが肥大化しやすい • 同じロジックが Service クラス間 に分散しやすく、変更に弱い 概要 • データの入れ物に処理も持たせる • オブジェクト指向プログラミング • Model はドメインロジックを担当 • Service はユースケースを担当 メリット • Service クラスが肥大化しにくい • 同じロジックが分散しにくく、変 更に強くなりやすい デメリット • 学習コストが高い
39. ドメインモデルを使う構成例 • 例えば、アプリケーション層とドメイン層を分離した 4 層の構成があります • 以下のような構成を「レイヤードアーキテクチャ」と呼びます プレゼンテーション層 アプリケーション層 データアクセス層 （インフラ層） Controller View 利用者とやりとり UI Service (UseCase) ユースケース Record データの入れ物 ドメイン層 Domain Model ドメインロジック Output (DTO) Service の戻り値 Gateway (DAO) DB とやりとり ※ 実際には、次の Repository パターンも使う例をレイヤードアーキテクチャと呼ぶことが多いと思われます
40. Repository パターン • 以下は、DB のテーブル都合ではなく、ドメインモデルの都合でデータを 読み書きする「Repository パターン」を導入した構成です プレゼンテーション層 アプリケーション層 データアクセス層 （インフラ層） Controller View 利用者とやりとり UI Service (UseCase) ユースケース Record データの入れ物 ドメイン層 Domain Model ドメインロジック Output (DTO) Service の戻り値 Gateway (DAO) DB とやりとり ※ Repository の実装に Table Data Gateway を使うのはあくまで一例で、実装はどんな方法でも構いません Repository
41. アプリケーション設計の観点 • 層分け：3 層・レイヤード・ヘキサゴナル・オニオン • プレゼンテーション：MVC・MVVM • ビジネスロジック：トランザクションスクリプト・ドメインモデル • データアクセス：Table Data Gateway・Repository ポイントは、「層分け」と「各層の実装方式」の観点があり、 様々な組み合わせがありえるということです
42. アーキテクチャの組み合わせ例 • レイヤード + MVC + ドメインモデル + Repository • Repository の内部実装は Table Data Gateway プレゼンテーション層 アプリケーション層 データアクセス層 （インフラ層） Controller View 利用者とやりとり UI Service (UseCase) ユースケース Record データの入れ物 ドメイン層 Domain Model ドメインロジック Output (DTO) Service の戻り値 Gateway (DAO) DB とやりとり Repository
43. アプリケーション設計の学習のポイント • アプリケーション設計には、以下のように異なる観点があります ◦ どのように層を分けるか ▪ 3 層・レイヤード・ヘキサゴナル・オニオン... ◦ 各層をどのように実装するか ▪ MVC・MVVM・MVP... ▪ トランザクションスクリプト・ドメインモデル... ▪ Table Data Gateway・Repository… ◦ ドメインモデルをどう設計・実装するか アプリケーション設計に関する書籍を読んだりするときは、 どの観点の話なのか注意してみると理解しやすくなることがあります
44. 「Controller に全部書く」からのステップアップ 例 1
45. 例 1 • ノンフレームワーク・Express などの軽量なフレームワークで、Controller に SQL まで書かれている場合... プレゼンテーション層 ビジネスロジック層 データアクセス層 Controller View Record 利用者とやりとり UI ユースケース ドメインロジック データの入れ物 DB とやりとり
46. データアクセスの分離 • 例えば、まずデータアクセス用のクラスを設けてみます プレゼンテーション層 ビジネスロジック層 データアクセス層 Controller View Record 利用者とやりとり UI ユースケース ドメインロジック データの入れ物 Gateway DB とやりとり
47. プレゼンテーションとビジネスロジックの分離 • Service を設けて、ビジネスロジック（ユースケースとドメインロジック）を 移動します プレゼンテーション層 ビジネスロジック層 データアクセス層 Controller View Record 利用者とやりとり UI データの入れ物 Gateway DB とやりとり Service ユースケース ドメインロジック
48. ドメインロジックの分離 • ドメインロジックは、Domain Model に持たせます （さらに、ドメイン層を分けたり、Repository パターンを導入したり...） プレゼンテーション層 ビジネスロジック層 データアクセス層 Controller View Record 利用者とやりとり UI データの入れ物 Gateway DB とやりとり Service ユースケース Domain Model ドメインロジック
49. ポイント • ポイントは、クラスごとの「役割分担」です • 他にも、「表示用の変換は Presenter」といった分担も考えられます プレゼンテーション層 ビジネスロジック層 データアクセス層 Controller View Record 利用者とやりとり UI データの入れ物 Gateway DB とやりとり Service ユースケース Domain Model ドメインロジック
50. 「Controller に全部書く」からのステップアップ 例 2
51. 例 2 • 今度は Rails や Laravel などで ActiveRecord 系 OR マッパーを使う例です • よくある苦しくなりやすい構成は、以下のような役割分担です プレゼンテーション層 ビジネスロジック層 データアクセス層 Controller View Model 利用者とやりとり UI ユースケース ドメインロジック DB とやりとり データの入れ物
52. 本来のアクティブレコードパターン • アクティブレコードパターンは、「DB のレコードと対応するクラスを作成 し、データアクセスのメソッドと、ドメインロジックを持たせる」ものです • つまり、アクティブレコードのモデルの役割は、本来は以下の 3 つです ◦ データベースのレコードと対応するデータを持つ ◦ データアクセスのメソッドを持つ ◦ ドメインロジックを持つ アクティブレコード系 OR マッパーを使うと、ドメインロジックが DB に強く依存する代わりに、実装量が非常に少なくなります
53. MVC + 本来のアクティブレコードの構成 • MVC とアクティブレコードパターンを組み合わせる場合は、以下のような 構成になるのが本来的です プレゼンテーション層 ビジネスロジック層 データアクセス層 Controller View Model (ActiveRecord) 利用者とやりとり UI ユースケース ドメインロジック DB とやりとり データの入れ物
54. ユースケースの分離 • もし Controller からユースケースを分離したい場合は、Service ( または UseCase) クラスを設ける手法を使うことができます プレゼンテーション層 ビジネスロジック層 データアクセス層 Controller View Model (ActiveRecord) 利用者とやりとり UI ドメインロジック DB とやりとり データの入れ物 Service (UseCase) ユースケース
55. ActiveRecord による Repository の実装 • ActiveRecord や Eloquent で Repository の実装も可能ですが、ActiveRecord のメリットは非常に弱くなります（あまりおすすめしません） プレゼンテーション層 ビジネスロジック層 データアクセス層 Controller View ドメインモデル 利用者とやりとり UI ドメインロジック Service (UseCase) ユースケース ActiveRecord DB とやりとり データの入れ物 Repository 呼び出し ActiveRecord とは関係ない ドメインロジックのためのモデル
56. フレームワークなどの特性を活かす • MVC + ActiveRecord 系 OR マッパーで、少ないコードで実装できることが魅 力のフレームワークであれば、その特性を活かした構成が良いと思います プレゼンテーション層 ビジネスロジック層 データアクセス層 Controller View Model (ActiveRecord) 利用者とやりとり UI ユースケース ドメインロジック DB とやりとり データの入れ物
57. 設計とプログラミング言語・フレームワーク • 様々な言語・フレームワークで使える基本をおさえつつ... 「言語やフレームワークに適した設計を採用すること」 「設計手法に適した言語やフレームワークを採用すること」 が重要だと思います 設計手法にも「常に正解」なものがあるわけではないので、 使っている技術や状況と、うまく適合させましょう
58. 参考文献 • 『エンタープライズアプリケーションアーキテクチャパターン』 ◦ マーチン・ファウラー (著), 株式会社テクノロジックアート (翻訳), 長瀬嘉秀 (翻訳, 監修), 2005, 翔泳社 • 『エリック・エヴァンスのドメイン駆動設計』 ◦ エリック・エヴァンス (著), 今関 剛 (監修), 和智 右桂 (翻訳), 牧野 祐子 (翻訳), 2011, 翔泳社 • 『実践ドメイン駆動設計』 ◦ ヴォーン・ヴァーノン (著), 髙木 正弘 (翻訳), 2015, 翔泳社 • 『Clean Architecture 達人に学ぶソフトウェアの構造と設計』 ◦ Robert C.Martin (著), 角 征典 (翻訳), 高木 正弘 (翻訳), 2018, KADOKAWA • 　 『．ＮＥＴのエンタープライズアプリケーションアーキテクチャ 第２版』 ◦ Dino Esposito (著), Andrea Saltarello (著), 日本マイクロソフト (監訳), クイープ (翻訳), 2015, 日経BP • 『現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法』 ◦ 増田 亨 (著), 2017, 技術評論社
59. 改めて整理するアプリケーション設計の基本
60. 宣伝 • つい先日、Udemy で今日のテーマの分野の講座をリリースしました リバーシで学ぶアプリケーション設計入門 今日のテーマの分野を、具体的な実装含め解説した講座です アプリケーション設計に大きく関わる仕様の整理から、 TypeScript での実装例まで解説しています エラーの解決や疑問点なども、できるだけサポートします クーポン付き URL を共有させていただくので、 ご興味ある方は手にとっていただけると嬉しいです ※ Speaker Deck の説明欄にも貼っています
61. Appendix
62. ドメイン層を中心にした構成例（1/2） • 依存性逆転の原則を適用することで、ドメイン層を中心にできます プレゼンテーション層 アプリケーション層 データアクセス層 （インフラ層） Controller View 利用者とやりとり UI Service (UseCase) ユースケース ドメイン層 Domain Model ドメインロジック Output (DTO) Service の戻り値 Repository DB とやりとり << interface >> Repository 実装クラス
63. ドメイン層を中心にした構成例（2/2） • 円を書いてみると、依存が内側だけに向かっていることが分かります プレゼンテーション層 アプリケーション層 データアクセス層 （インフラ層） Controller View 利用者とやりとり UI Service (UseCase) ユースケース ドメイン層 Domain Model ドメインロジック Output (DTO) Service の戻り値 Repository DB とやりとり << interface >> Repository