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

はじめに

現場で役立つシステム設計の原則第3章 業務ロジックをわかりやすく整理するを読んで、

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

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

 

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

3章では業務ロジックが至る所にちらばってしまう原因と、

その対策として業務データとロジックを1箇所に集めるドメインモデル方式についての説明がメインでした。

 

この章の考え方を抑えて設計できる人が、

僕が最近面倒を見ることになった自社プロダクトの設計を最初にやってくれてたら

どれだけ楽だったか。。。。とつくづく思うような章でした。

 

クラスをデータの入れ物と捉えるのではなく業務ロジックの置き場と捉える

setterやgetterだけが書かれたクラスは、それを利用する側はそのクラスから値をgetして、

判断、加工、計算をするのが前提となる。

 

さらに、至る所で値をgetして判断、加工、計算ができ、

同じような業務ロジックが散らばりどこにどの業務ロジックを書くべきかも曖昧になる。

 

その対策として共通部品を作ると・・・

 

うまく共通化しきれずフラグなどを持たせてこのケースはこうみたいなことをすることになる。

結局使う側がいろんなフラグを駆使して共通部品を使うのでハードルが上がり、

自分で作った方が簡単だからと共通部品が使われなくなる。

 

といった記載が本にありました。

 

正直、Javaでプログラムを書いているのに、クラスをデータの入れ物として捉えて

大惨事になっているプロダクトはほんとに現場でよく見かけます。

(直近面倒をみているプロダクトもまさにそうなっていて今必死にリファクタしてたり、、、)

 

クラスをデータの入れ物クラスと捉える場合と、

ロジック置き場と捉える場合との違いのイメージはこんな感じ。

 

 

使い回しできるロジック置き場クラスを作るという考え方で設計を行うことが重要で、

この違いは保守開発のフェーズで大きく出ます。。。。

 

僕がJavaの勉強をしていた大学時代にこの考え方もセットできちんと抑えられていたら、

どれだけ今までダメな設計をせずに済んだのだろうと昔をつい振り返りつつ、、、

新人教育でJavaの書き方Webアプリの作り方を教えるのと同じように、

この考え方だけは、せめて僕がいる現場に配属された新人に教えてあげたいなと思いました。

(自分も1年目でこの考え方を教わってたらもっと違ったかな、、)

 

パッケージの設計も重要!!パッケージプライベートで依存関係を制御する

以前、「普通のプログラマの普通の設計」という勉強会に参加した際にも、

パッケージの設計まできちんとできるプログラマは1段上のレベルのプログラマ。

というような話がありました。

 

その時の勉強会で気になったポイントをまとめた記事があるので、

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

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

 

クラスが増えてきて、クラスにわかりやすい名前をつけるだけでなく、

業務フローの工程毎にパッケージを切って、パッケージ間の依存関係も業務フローの依存関係に合わせる

形にしてパッケージプライベートを利用することで、

仕様変更時の影響範囲を限定的にできる。というようなことが書いてありました。

 

現場でパッケージプライベートをこのように利用したソースコードは今まで見たことがないので、

1段上のレベルのプログラマと現場で出会ったことがないってことか。。。とも思いつつ、、、

 

なんでもかんでもpublicで定義するのではなく、パッケージの設計を適当にしてたらダメ!!

だということに改めて考え直す機会になりました。

 

データモデル方式とドメインオブジェクト方式

先ほど図でイメージを紹介したクラスをデータの入れ物と捉える方式がデータモデル方式で、

クラスをロジックの置き場と捉える方式がドメインオブジェクト方式に近いと僕は理解しています。

 

MEMO

ドメインとはシステムで解決したい課題領域のこと

 

ビジネスルールの中ではデータの判断、データの加工などが必要。

それらデータ、判断・加工のロジックを同一クラスにまとめ、

同一クラスのインスタンス変数を利用して判断・加工ロジックを作る。

そのように整理していくと、使いまわすことができ、判断や加工ロジックが至る所に散らばる心配がなくなる。

このように整理していくのがドメインオブジェクトの方式です。

 

ここからはおまけですが・・・

以前僕がドメイン駆動設計の練習で

ポイントシステムというテーマでドメインに登場する概念、データ、振る舞いを整理して、モデリングし、

それをもとにソースコードを書いてテストコードでテストして・・を繰り返していたことがあるのですが、

その際のモデリングの作業では今回のドメインオブジェクト方式の考え方をかなり意識しました。

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

ドメイン駆動設計の練習!!モデリング〜サンプルプログラム・テストコード作成(まとめ記事)

 

まとめ

現場で役立つシステム設計の原則第3章 業務ロジックをわかりやすく整理するを読んで、

個人的には特に以下2点の考え方は重要だと感じました。

 

  • クラスをデータの入れ物と捉えるのではなく業務ロジックの置き場と捉える
  • パッケージの設計も重要!!パッケージプライベートで依存関係を制御する

 

手段の紹介ももちろん参考にできますが、

考え方やそう考える理由などを正しく把握する方が手段を把握するよりもはるかに重要!!!

って思います。

 

2022/3/22追記

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

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

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

現場で役立つシステム設計の原則を読んでみて(まとめ記事)|気付きと現場で取り入れたいことについて

コメントを残す

メールアドレスが公開されることはありません。

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください