DDDに興味が出てきたので現場で役立つシステム設計の原則を読んだ

新品価格
￥3,234から
(2019/11/22 09:00時点)

現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法
を読んだ

マスタカと言えばアーキテクター
そう恋を作るアーキテクターだ！
そんなわけで本書を読んでみた

・本書の内容
オブジェクト指向にDDDの考えを持ち込んで
システムの設計について説明した本

オブジェクト指向の理解が浅い人や
マスタカのようにDDDに興味がある人が
最初に読むならオススメできる本

・破壊的代入
一つの変数を使いまわすのを破壊的代入と呼ぶ
なので、目的別に専用のローカル変数を用意するのが
リファクタリングの最初の一歩になる

・ドメインオブジェクト
業務で使われる用語に合わせて
その用語の関心ごとに対応するクラスをドメインオブジェクトと呼ぶ
送料クラスが一例

・値オブジェクト
値を扱うための専用クラスを作るやり方を値オブジェクト

minusメソッドやplusメソッドが定義されて計算もできるようになる
返却値は新しいインスタンスになる。
setterメソッドは作らない

またマイナスは取らない等も値オブジェクトの中で制限する

・コレクションオブジェクト、ファーストクラスオブジェクト
コレクション型のデータやロジックを特別扱いにして
コレクションを1つだけ持つ専用クラスを作るやり方
コードが単純になる

・状態遷移
enumで状態は定義
map関数で現在,set(次の遷移先)
という形で定義するとif文がなくなるので楽

・三層アーキテクチャ
プレゼンテーション層
アプリケーション層
データソース層

・ドメインモデル方式
三層+ドメインモデルが良いのではとのこと。
ドメインモデルはデータだけでなくロジックも持ってる

・業務の関心ごと
関心ごとは、ヒト、モノ、コトに分類できる
そして、コトに注目すると整理しやすい

・業務ロジック
業務ロジックはサービスクラスに書かずにドメインオブジェクトに任せる
千円単位の表示等の表示も持つのはあり
presentationが簡単にかけるようになる

・サービスクラスを小さくする方法
登録と参照のサービスクラスを分ける
組み合わせ用のサービスクラスを作る

・データベースの工夫
insert文とdelete文にしてupdateはしない
カラムの追加はせずテーブルの追加

うーん、これだけは同意できない。
update使わないで済むならそうしたいよねってのはわかるけど

・APIでやるかアプリでやるか
業務ルールと呼べないような単純の合計計算の場合はAPIで
アプリケーションに依存したロジックの場合はアプリで

・APIの分離
コアとなる基本API
拡張API：コアAPIを組み合わせたモノ
個別対応API：BFF

この分類に基づいてAPIを今後どのように進化させるか考える

本書はとてもためになりました
読んだ感想としてはエンジニアなら最初に知っておくべきかなって内容です
とても良い本なので、新入社員からDDDが必要になったタイミングでぜひ読んでみてください