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

by os1ma

Slide 1

Slide 1 text

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

ビジネスロジックとは

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

Appendix

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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