やっと読めるようになった「現場で役立つシステム設計の原則」についてアウトプット

何回かトライしたけど消化不良で理解できていなかったのですが、最近また読み進めてみたら前よりも理解できるようになっていたのでアウトプットします。

https://www.amazon.co.jp/%E7%8F%BE%E5%A0%B4%E3%81%A7%E5%BD%B9%E7%AB%8B%E3%81%A4%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E8%A8%AD%E8%A8%88%E3%81%AE%E5%8E%9F%E5%89%87-%E5%A4%89%E6%9B%B4%E3%82%92%E6%A5%BD%E3%81%A7%E5%AE%89%E5%85%A8%E3%81%AB%E3%81%99%E3%82%8B%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E6%8C%87%E5%90%91%E3%81%AE%E5%AE%9F%E8%B7%B5%E6%8A%80%E6%B3%95-%E5%A2%97%E7%94%B0-%E4%BA%A8/dp/477419087X

# 1章 小さくまとめてわかりやすくする
### 小さなクラスでわかりやすく安全に

|データの種類|用途|Javaでの記法|
|:--:|:--:|:--:|
|数値|金額、数量|int,BigDecimal|
|日付|予定日、注文日、有効期限|LocalDate|
|文字|指名、電話番号、説明|String|

金額や数量をnumber型でそのまま使ってしまうとnumber型ならどんな値でも入ってしまいます。
例えば個人でリンゴを買うとして数量に`1000000000(十億)個`というような値も入ってしまいます。
これはアプリケーションとして安全ではありません。

これを防ぐには数量のためのクラスを作る必要があります。

```java
class Quantity {
  static final int MIN = 1;
  static final int MAX = 100;
  
  int value
  
  Quantity(int value) {
    if(value < MIN) throw new
      IllegalArgumentException("不正:" + MIN + "未満");
    if(value > MAX) throw new
      IllegalArgumentException(("不正:" + MAX + "超");)
  }
}
```

上記のようにすることで`1000000000(十億)個`というありえない数値が入ることを防ぐことができます。
また、ここに記述することで、例えばバックエンド側のいくつかのコードに以下の記述をしなくても良いことになります。

```java
if(value < MIN) throw new
      IllegalArgumentException("不正:" + MIN + "未満");
    if(value > MAX) throw new
      IllegalArgumentException(("不正:" + MAX + "超");)
  }
```

|データの種類|ビジネスロジック
|:--:|:--:|
|金額|合計の計算、3桁ごとのカンマ編集をして、千円単位を丸めて加工して返す|

また上記のビジネスロジックがあったとして、それをクラスの中に記述して、色々な場所で呼び出して使用することができます。

https://www.weblio.jp/content/%E3%83%93%E3%82%B8%E3%83%8D%E3%82%B9%E3%83%AD%E3%82%B8%E3%83%83%E3%82%AF

このような値を扱うための専用クラスを`値オブジェクト`と呼びます。

### 呼び出し側でどうやって使う?

`separateEveryThreeDigits`という3桁ごとのカンマ編集をして、千円単位を丸めて加工して返すメソッドが金額クラスであるMoneyにあったとして、
こんな感じでどこでも使えるようになります。

```ts
const money = new Money(1000).separateEveryThreeDigits()
```

正直以下のようなやり方でもいけるんですが、これだと他のメソッドも使用できてしまうので(Number型のため)、Moneyという関心事に対してすべきでない処理もすることができてしまい、安全ではありません。
また、安全であるということに加えて、Moenyという値オブジェクトを参照することで他にどのようなビジネスロジックがあるか知ることができます(型が仕様を語る)。

```ts
const money = Number(1000).toLocalString()
```

# 3章 業務ロジックをわかりやすく整理する
### 業務アプリケーションのコードの見通しが悪くなる原因

> 従来の手続き型の設計では、アプリケーションのクラス構成を、データを格納するデータクラスと、ロジックを記述する機能クラスに分けることが基本になります。

### データクラスのいろいろな呼び方
|名前|説明|
|:--:|:--:|
|Data Transfer Object|サブシステム間でデータをやり取りするための設計パターン|
|Entityクラス|データベースとデータをやり取りするためのデータの入れ物クラス|
|Formクラス|画面とデータやり取りするためのデータの入れ物クラス|

> データクラスは`getQuantity()`/`setQuantity()`など、いわゆる`getter`/`setter`と言われるメソッド群だけを持ちます。

> 業務アプリケーションでは、業務ロジックを整理するために、画面インターフェース/業務ロジック/データベース入出力の3つの関心ごとを分離するために三層アーキテクチャーが一般的です。

### 三層アーキテクチャ

|名前|説明|
|:--:|:--:|
|プレゼンテーション層|画面や外部接続インターフェース|
|アプリケーション層|業務ロジック、業務ルール|
|データソース層|データベース入出力|

https://www.youtube.com/watch?v=gEvFwg3oPBY

### getterとsetterがあるとどうなるか

- いろいろな場所で同じ業務ロジックが重複して書かれる
- どこに業務ロジックが書いてあるか見通しが悪くなる

修正するときにgrepして頑張って修正するみたいな感じになります。

データクラスを使用してアプリケーション層に業務ロジックを書くとどこに何が書いてあるかの見通しが悪くなりがちです。

そうならないために
データ + ロジックが一体になったクラスを作ります。
設計時には以下のことに気をつけます。（他にもありますが割愛）

- メソッドをロジックの置き場所にする
- ロジックをデータを持つクラスに移動する

#### メソッドをロジックの置き場所にする
データクラスがうまくいかないのは、自分がデータをそのまま別のクラスに渡してしまうから(getterがあるから)です。
それを防ぐにはgetterをなくして

```java
class Person {
  private String firstName;
  private String lastName;

  String getFirstName() {
    return firstName;
  }

  String getLastName() {
    return lastName;
  }
}
```

上記のようなクラスは使用する側にデータを渡すだけのクラスです。

ここにビジネスロジックを追加します。

```java
class Person {
  private String firstName;
  private String lastName;
  ...

  String FullName() {
    return String.format("%s %s", firstName, lastName);
  }
}
```

業務の関心事が欲しいものをそのまま渡します。

例)
リンゴジュースが欲しいと思ったときに
上のコードはリンゴを渡してくる(こっちでどうにかしないといけない)
下のコードはリンゴを絞ってリンゴジュースにして渡してくれる

#### ロジックをデータを持つクラスに移動する

下のコードのメリット
- データを持つ側のクラスにロジックが増える
- データをgetしていたクラスからロジックが減る
- 使う側のクラスはデータをgetするのではなく、そのデータを使った計算結果を受け取るようになる

#### 三層の関心事と業務ロジックの分離を徹底する
> 業務データと業務ロジックを1つにまとめたオブジェクトを`ドメインオブジェクト`と呼びます。

https://www.weblio.jp/content/%E3%83%89%E3%83%A1%E3%82%A4%E3%83%B3#:~:text=%E3%83%89%E3%83%A1%E3%82%A4%E3%83%B3%E3%80%90domain%E3%80%91,%E3%81%A7%E3%81%8D%E3%82%8B%E3%82%88%E3%81%86%E3%81%AB%E3%81%97%E3%81%9F%E3%82%82%E3%81%AE%E3%80%82

ドメインオブジェクトは三層アーキテクチャのどこからでも参照することができます。
なのでデータクラスでgetterして各層で`加工/判断/計算`していた箇所をこのドメインオブジェクトのメソッドを使用して使うことができるのです。
このようなアーキテクチャを`三層 + ドメインモデル`と呼びます

![段落テキスト.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/660329/ea74ea74-eccb-56bd-d01d-867a4064a137.png)


# 5章 アプリケーション機能を組み立てる

![段落テキスト (4).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/660329/6e4ceb7d-cff3-649c-6181-d8605ce296d9.png)

#### 三層 + ドメインモデルにおけるアプリケーション層のクラスの役割
- プレゼンテーション層からの依頼を受ける
- 適切なドメインオブジェクトに判断/加工/計算を依頼する
- プレゼンテーション層に結果(ドメインオブジェクトを返す
- データソース層に記録や通知の入出力を指示する

> アプリケーション層のクラスはプレゼンテーション層に対して、業務サービスを提供します。サービスを提供するという意味で、アプリケーションサービスクラス、もしくはサービスクラスと呼びます。

サービスクラスの設計で気をつけるポイント
- 業務ロジックをサービスクラスに書かずにドメインオブジェクトに任せる
- 画面の複雑さをそのままサービスクラスに持ち込まない

#### 業務ロジックをサービスクラスに書かずにドメインオブジェクトに任せる
> 業務アプリケーションを段階的に作っていくときにサービスクラスのメソッドに業務ロジックを直接書いてしまうことが、その時点では最もわかりやすく手っ取り早いことはよくあります。
しかし、サービスクラスに業務ロジックを書き始めると、手続き型のプログラミングで起こりがちなコードの重複が始まります。
そうならないために、段階的にコードを追加するときには、いつも設計の改善を考えます。適切なドメインオブジェクトがなければ、ドメインオブジェクトの追加を考えます。

#### 自分が今の段階で疑問なこと
サービスクラスに書いてある条件などはどこからどこまでがビジネスロジック?
ドメインに今サービスクラスに書いてある条件をドメインオブジェクトに組み込んだら半端ない行数になりそうだけどそれで良い?

# 7章 画面とドメインオブジェクトの設計を連動させる
#### 画面とソフトウェアを関係づける

> 利用者が何に関心事があり、どういうことをやりたいかは、画面で視覚的に表現されます。利用者の関心事を可視化した画面と、ドメインオブジェクトの不一致は設計改善の良い手がかりです。

- 画面での項目の並び順と、対応するドメインオブジェクトのフィールドの並び順が一致していない。

以下のようなクラスがあって

```java
class Book {
  long id;
  BookNumber number;
  
  Title title;
  Author author;
  Publisher publisher;
  
  BookType type;
  Price unitPrice;

  LocalDate published;
  LocalDate registerd;
}
```

画面上での項目の並び方が以下のように並んでいるときに
- 書名
- 価格
- 発行年月日
- 業者
- 本の種類

画面上での項目の並びはユーザーの関心事と一致するため、ドメインでのインスタンス変数の並びも一致するのが良いと書いてあります。

修正後は以下のようになります。

```java
class BookSummary {
  
  Title title;
  Price unitPrice;
  LocalDate published;

  Author author;
  BookType type;
}
```

画面側での項目の並びが変わっときにドメインオブジェクトのインスタンス変数の並びも更新するのが良い設計だそうです。

# 8章 アプリケーション間の連携
TBA

### 感想
今の職場ではDDDを採用しているのですが、前職では手続き型100%で全てのコードを記述していたため、今の職場にきてから最初の頃は「データを取得するためになぜこんな面倒くさいことをしなくてはいけないんだ....」と思っていました。
でも不具合修正の時など、コードを見ずに修正箇所を特定できたり、修正箇所が少なかったりなどメリットを身をもって体験することができ、DDD、オブジェクト指向すげぇってなることが多々ありました。
今まで何回かこの本を読んでは途中でわからなくなって投げ出すということをしていたのですが、それはそもそもDDDの根幹であるクラス、オブジェクト指向について全く知らなかったためであるかなと今になって思います。(今でもそんなに知らないけど...)
クラス、オブジェクト指向については以下の本がめちゃめちゃわかりやすいです。(java知らなくても読める)

https://www.amazon.co.jp/%E3%82%B9%E3%83%83%E3%82%AD%E3%83%AA%E3%82%8F%E3%81%8B%E3%82%8BJava%E5%85%A5%E9%96%80-%E7%AC%AC3%E7%89%88-%E3%82%B9%E3%83%83%E3%82%AD%E3%83%AA%E3%82%B7%E3%83%AA%E3%83%BC%E3%82%BA-%E4%B8%AD%E5%B1%B1%E6%B8%85%E5%96%AC/dp/4295007803/ref=asc_df_4295007803/?tag=jpgo-22&linkCode=df0&hvadid=342518373760&hvpos=&hvnetw=g&hvrand=13044044328554919178&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=1009461&hvtargid=pla-838775058853&psc=1&th=1&psc=1