読んだ本

 

前書き

GWに読んだ本、せっかく読んだので忘れないようにBlogにまとめようと思った。

読んだ本：現場で役立つシステム設計の原則 

著者：増田　亨

 

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/ref=sr_1_1?adgrpid=119676456950&dib=eyJ2IjoiMSJ9.sf0dx8kUfM4vNq5sWnkHIk28_qYlN6sTjHZE0xSUbwGq1yu2X9euuKgnk3Np9aDJH2NbOOHGpjySXGL6HoXRlRe3s7owcTo3HuS4X3En4Q6CtCQMJDJkpyjOtUx57_DK679mfOJ4YjxvhtsWvl2uOHqXxB9te36SsIKRR3VMBuXCwOhDpKA75RtD5veVTsDy6IQedcmHGUGk1x_lDajHJpc-BJmH-pCyZ-yQh__rGUo.a66PleYz9GTtkXterPTQuawzNidcOgPvycsi_6H6zjI&dib_tag=se&hvadid=678980112366&hvdev=c&hvqmt=e&hvtargid=kwd-330189736777&hydadcr=27268_14738204&jp-ad-ap=0&keywords=%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&qid=1714815384&sr=8-1

 

 

感想

今まで自分が4年間開発してきたシステムはオブジェクト指向の顔をした手続き型だったんだなと思った。簡易ドメイン駆動モデル（DDD）だとは聞かされていたが、オブジェクト指向からは離れた手続き型であることを思い知らされてむなしくなった。

これを機に、とりあえずオブジェクト指向の扉を開きたいと思った。

この本はオブジェクト指向というかなり広い概念について網羅的にかかれている。GWの前半にDDDの本を読んだけどそれよりはすぐに実践するというより、こういう考えをもって開発しよう、プロジェクトを始めようといったニュアンスが強いかも

 

学んだこと

  1. とにかくドメインモデル（エンティティ）にはフィールドだけでなく、ロジックも束ねてまとめる。ドメインモデルをデータとロジックのセットで考える
    ドメインサービスといった楽なサービスを頼らず、なるべくドメインモデル内に書くことを心掛ける
  2. 三層アーキはドメインモデルを含めた三層アーキ＋ドメインモデルを基本構成とする。
  3. repositoryはDBに依存せずにドメイン毎に作る。DDDっぽい書き方だと、repositoryとその実装クラスのdatasourceはドメイン毎にクラスを切って、datasource内のDBアクセスを実際のDBに即したDBに登録する感じにする
    例えば、注文と注文の詳細情報の2つを管理するテーブルに対して、注文登録というユースケースを実現する場合、注文テーブル・注文詳細テーブルそれぞれに対してrepositoryを切るのではなく、repositoryはあくまで注文クラス1つだけにし、その実装クラスであるdatasourceで2つのテーブル（注文・注文詳細）に対してinsertするようなロジックを記載する

以上の3つが学び。

 

以降では、それぞれの章で学んだことを記載する

第一章：小さくまとめてわかりやすくする

変更が大変なプログラムの特徴

  1. メソッドが長い
  2. クラスが大きい
  3. 引数が多い

変更が楽になるプログラムの書き方

  1. わかりやすい名前を使う
    量をaやb、q、qtyと書かずにquantityとかく
  2. 長い処理をまとめる、空行を使う。切る
  3. 目的ごとに変数を使う
  4. メソッドに切る
  5. 重複した処理をなくす
  6. 狭い関心毎に特化したクラスを作る

基本データ型を使わずに、値オブジェクトを作る

値オブジェクトとは、フィールドを1つや2つだけ持った小さなクラス。そこに基本データ型だけではチェックできないことをチェックする。
例えば、郵便番号をただのstringにするのではなく、郵便番号クラスを作ってハイフンの前後で別のフィールドを定義するよな感じ。

⇒ただ個人的な感想では、Spring的にはBeanValidationを使えば値オブジェクトはいらないかなぁという感想。何か不具合のあるデータはだいたい登録系でBeanValidationつけれると思うから

ファーストコレクションにする。ファーストコレクションとはリストやコレクションを使わずに、リストを1つだけフィールドにもったクラスを作る。リストへの操作は全てこのクラスを介して行うようにする。そうすることでリストへの変更操作をクラス内に閉じ込める

第二章：場合分けのロジックを整理する

ifの処理をメソッド化する

elseを使わない。ガード節、早期リターンをする

条件に従ってインスタンスを変化させたい場合はIFを使う（多態）

enumを使って状態遷移を明確にする

第三章：業務ロジックを分かりやすく整理する（大事）

データクラスの色々な呼び方

  • DTO・・・サブシステム間でデータをやりとりするための設計パターン
  • Entity・・・DBとデータをやりとりするためのデータの入れ物
  • Form・・・画面とデータをやりといするためのデータの入れ物
  • JavaBean・・・開発ツールやフレームワークを意図して制定された共通のデータアクセス仕様に準拠したクラス

業務ロジックを重複させないための設計

  • メソッドをロジックの置き場所にする
  • ロジックをデータを持つクラスに移動する
  • 使う側のクラスにロジックを書き始めたら設計を見直す
  • メソッドを短くしてロジックの移動をやりやすくする
  • メソッドでは必ずインスタンス変数を使う
  • クラスが肥大化したら小さく分ける
  • パッケージを使ってクラスを整理する

三層アーキ＋ドメインモデル

  • プレゼンテーション層・・・UIなど外部との入出力を受け持つ
  • アプリケーション層・・・業務機能のマクロな手順の記述
  • データソース層・・・データベースとの入出力を受け持つ
  • ドメインモデル・・・業務データと関連する業務ロジックを表現したドメインオブジェクトの集合

第四章：ドメインモデルの考え方で設計する

特になし

第五章：アプリケーション機能を組み立てる

SpringFrameworkですぐ実現可能。

サービスクラスの設計はごちゃりやすい

  • ドメインオブジェクトが業務ロジックの置き場所として十分機能していない
  • プレゼンテーション層の関心毎に振り回される
  • DBの入出力の都合に引きずられる

ユースケースの複合系は小さなAPサービスとそれを活用する大きなAPサービスに分ける⇒ただトランザクションがちょい気になる

第六章：データベースの設計とドメインオブジェクト

オブジェクトとテーブルは別物

UPDATEをしない！？

第七章：画面とドメインオブジェクトの設計を連動させる

タスクベースのユーザインタフェース・・・Amazonの商品購入までのプロセスのようなもの。商品購入までには①購入者の情報入力②商品の登録③決済方法の登録④配達手段の登録　など複数プロセスにわたって必要事項を入力しなければならないが、そのすべては同時に行う必要はなく、事前に1つ1つ行っておくことが出来る。用途に特化した小さな部品に分解すること

 

画面表示項目用の数字のカンマ区切りやフロントエラーメッセージ、cssのプロパティなんかも業務ロジックが入っているんならバックで返却すべきという考え

⇒これはさすがに面倒だと思う。

第八章：アプリケーション間の連携

アプリケーション間の連携方式

  • ファイル転送
  • DB共有
  • WebAPI
  • メッセージング（非同期通信・ソケットAP？）

使いにくいWebAPI

  • データを取得するために指定するパラメータが多い
  • 取得したデータの項目数が多い
  • 登録時に指定しなければいけないデータ項目が多い

REST Controller

SwaggerUI

複雑なWebAPI

  • コアとなる基本API・・・どの利用者にも共通するAPI
  • 拡張API・・・利用者がより使いやすいようにコアを集めた複合API
  • 個別対応API・・・個社API

第九章：オブジェクト指向の開発プロセス

書かれていること：ウォーターフォールではオブジェクト指向無理や、アジャイルやろう。どんだけ手の込んだ設計書作っても開発者が設計者と違うのならいいものができるわけないし、後工程の変更でどうするの？設計と開発は一緒にやろ

第十章：オブジェクト指向設計の学び方と教え方

書かれていること：オブジェクト指向の効力を感じれるのはリリース後の改善活動をしているとき。まずは今作っているコードを改善しよう

リファクタリングの対象。リファクタリングは少しずつ始めよう

  • 重複したコード
  • 長いメソッド
  • 巨大なクラス

 

いい本