現場で役立つシステム設計の原則第４章を読んで｜気付きや今後参考にしたいことなどをまとめてみました

はじめに

現場で役立つシステム設計の原則第４章　ドメインモデルの考え方で設計するを読んで、

今まで現場で設計をしてきた自分の観点で、

特に重要だと感じたポイント、気付き、今後参考にしていくべきだと感じたことをまとめてみました。

2022/3/22追記

現場で役立つシステム設計の原則を読んでみて、

今後現場で取り入れたいこと、気付きなどなど

まとめ記事を作ったので是非こちらも見てください！！

現場で役立つシステム設計の原則から学んだことや気づきまとめ

現場で役立つシステム設計の原則第４章を読んでの気付きなど

４章ではドメインモデルの設計の進め方についてメインで書かれていました。

仕様変更時に変更をシンプルで安全にするための考え方や設計の進め方だったり、

業務知識の整理のやり方などなどについて説明されていた章でした。

仕様変更が危険で工数もかかり、超複雑な今まで自分が保守開発したことのある過去のシステムを

この考え方で再設計してみたい・・・と思わせるような章でした、、、

業務を理解するための分析とソフトウェアを実現するための設計が一体になった活動がドメインモデルの設計

ドメインモデルの活動では分析と設計は一体になった活動。

業務知識のない初期の段階でも、理解の確認のためにソースコードを書いて、

知識が増えてくるに従ってクラスやメソッドの内容が充実する。

業務を学びながら早い段階でコードを書き、コードを段階的に成長させていく。

そのため分析と設計は同じ人が実施するのが良い。

このような内容の記載が個人的には印象に残りました。

現場でたまに見かけるのが、、、自分はアプリアーキテクトだ！！

細かい業務知識なんか知らん。けどシステムの基盤は自分がやる(だって自分は優秀なエンジニアだから)！！

みたいな・・・・

業務の分析を行おうとしない人が無責任に手を出してへんな共通化して部品作って、、、

こうやってできた基盤に乗っけて実際に業務要件を取り入れて開発していくと、

この基盤なしで開発させてもらえないかな。。。と思うような経験が大手の通信事業会社に

開発委託として参画したときありました。

アプリアーキテクトが業務知識なくても基盤開発していたシステム開発の時代は過去にはあったが、

最近では複雑なドメイン解決を行うシステムが求められるので、

業務を正しく分析して設計するのが普通だ。ということが過去参加した勉強会でも話がでていました。

興味がある方はこちら参照ください。

「祝完読！ しょぼちむのエヴァンス本のススメ」(勉強会)に参加してみた感想や気づきなど

業務で使われる言葉とクラスやメソッドを一致させる

業務で使われる言葉とクラス、メソッドを一致させると・・・

どこに何が書いてあるか特定しやすく、

仕様変更時の対象クラスが変更要求範囲と一致し、

変更の影響するソフトウェアの範囲が変更が関連する業務の範囲と一致する。

という内容が印象に残っています。

業務ロジックの変更内容としてはとてもシンプルなのですが、

業務で登場する概念をデータモデルクラス＋機能クラスで実装していて

いろんな箇所でその業務ロジックの一部ロジックを持って影響範囲が大きく

テスト工数も大きくなる。

というケースは今までの保守開発の経験の中で何度も体験しました。

業務で登場する概念を細かい部品に分けてそれを組み合わせて１つの業務を実現する。

部品は業務全体で使いまわせるようにする。

ように設計できていれば今までの残業時間や変更の危険に伴うドキドキを減らせたことか。。。

また、この内容を読んで改めて、

クラス名、メソッド名、パッケージ名などの名前は業務に登場する概念とマップさせて、

業務ロジックをどこに置くのか？？を明確にするために当たり前だけど重要だよなと思いました。

過去参加した勉強会でも名前の重要性について取り上げられていたので、

興味がある方はこちらご覧ください。

「普通のプログラマの普通の設計」(勉強会)に参加してみた感想

ドメインオブジェクトを見つけるには業務の関心事の「コト」に注目する

業務の関心事の「コト」に注目すると、

その「コト」を発生する際の約束事(受注をするには在庫がないとだめよとか)があったり、

「コト」の時間的な前後関係(先にAのコトが起きて、Bのコトが起きた後にCのコトが・・)があったり、

コトには「ヒト」と「モノ」との関係があったり、

このあたりの関連する業務ロジックやドメインオブジェクトを発見する糸口となる。

という記載がありました。

今、自分は既存のデータモデル方式のプロダクトをドメインモデル方式にしようと、

現状の業務を分析してドメインオブジェクトを見つけてモデリングしているところで・・・

この観点で分析進めていこうと思います！！！

ドメインオブジェクトは一度作って終わりではなく洗練させていくもの

ドメインオブジェクトは一度作って終わりではなく、

部品としての使い勝手を確認しながら改善を続ける。

改善を続けることで、プログラム全体のわかりやすさと、変更の容易性をさらに向上できる。

この内容も自分の中では印象に残っています。

最初から完璧にできることはないという考え方のもと、

何度かサイクルを回して洗練させて設計と開発と分析を繰り返し行うことが重要だと、

僕も普段から意識しています。

また、

ドメインオブジェクトを使う側がシンプルであり続けるように、

使う側が複雑になるとそれはドメインオブジェクトの方へ複雑な処理を移したほうがいいかも。

使う側が他にもあるとこういう複雑な処理を至る所に書くことになるから注意！！

といった内容の記載もあったので、

業務の分析〜設計〜製造のサイクルを回す際に、

ここの意識をもつことが重要だと感じました。

まとめ

現場で役立つシステム設計の原則第４章　ドメインモデルの考え方で設計するを読んで、

この辺りは自分の経験的に重要だなと感じたので、

普段から意識して現場での作業をしていこうと思います。

第４章は比較的長めで他にも考え方の参考になる箇所はあったのですが、、、

興味がある方は実際に本を読んで自分自身で本に書かれてある考え方と

自分の考え方を比較してみると面白いと思います。

(もう一段自分自身レベルが上がったり、自分の引き出しが増えるはず)