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

はじめに

現場で役立つシステム設計の原則第５章　アプリケーション機能を組み立てるを読んで、

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

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

2022/3/22追記

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

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

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

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

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

５章はドメインモデルで設計したドメインオブジェクトを組み合わせて、

１つの業務サービスを実現するアプリケーション層のサービスクラスを作る際、

なぜごちゃごちゃしがちなのか？？その対策としてどういう設計思想が重要なのか？？

についてまとめてある章でした。

DB操作と切り離す、画面と切り離すという考え方とそのやり方については個人的には、

プログラマー2年目くらいの自分に聞かせたい・・・思える内容でした。

サービスクラスがごちゃごちゃする原因はドメインオブジェクトが機能していないかDBや画面に振り回されるから

まず、アプリケーション層のサービスクラスはドメインオブジェクトを組み合わせて

１つの業務サービスを実現する役割を担います。

このアプリケーション層に作るサービスクラスは、

ドメイン層のビジネスロジックを使ったり、データソース層のDB登録、検索を使うだけで

１つのビジネスサービスを実現したい。

ただ、実際には、

条件分岐ががっつり書かれてビジネスロジックが書かれたり、

画面用のデータ加工(1,000を1,000円に変換など)したり、

DB操作を手続き的にごちゃごちゃ書いたりなどなどしてしまっていることが多いです。

(実際僕が経験した現場でごちゃごちゃしていないサービスクラスを見たことはないです)

これらの原因として、

ドメインオブジェクトがビジネスロジックの置き場として機能していない。

画面レイアウトやDBのテーブルレイアウトに振り回されている。

これらが原因として考えられると本では述べられていました。

確かに、

ドメインオブジェクトに書いたビジネスロジックで加工、判断が全て足りていれば、

入り組んだ条件分岐をサービスクラスに書く必要はなくなり、

DB操作の具体的な実装をサービスクラスから切り離すことができれば、テーブルレイアウト変更などに

サービスクラスが影響を受けることはなくなるはずです。

(最初からその設計思想でスタートできていないシステムが多いから保守開発で困ってるのですが、、、)

動かすだけならサービスクラスにサクッと分岐や一部ビジネスロジックを書いてしまった方が楽。

サービスクラスに業務ロジックを書きたくなったらドメインモデル改良の機会

動かすだけならサービスクラスに分岐や業務ロジックを書くのが簡単だが、

サービスクラスに安易に業務ロジックを追加すると同じように

別のサービスクラスにも業務ロジックをかくことになる。

ドメインオブジェクトを追加するか改善の方向で修正を行うべき。

このような内容が本では述べられていました。

まさにその通りだなと・・・・

サービスクラスの設計の際に大切にしたい考え方の１つだと思います。

データベースの具体的な操作と業務の関心事とを分けて考える

データベースの具体的なselect文やinsert文のような単位を中心に考え始めると、

業務的な関心事との間に差がでてきて、業務的な関心事が薄れてくる。

(それは業務的な関心事とプログラムの単位をきれにマップできていない状態で、

業務仕様の変更に伴うプログラムの影響範囲が不自然な波及を生むことを表しているというのが自分の理解)

その対策として、

リポジトリに業務的な関心事をインタフェースで表現し、

その実装としてデータベースの具体的な操作を分けて実装する。

という内容が本では述べられていました。(一部自分の解釈も混ざってますが)

具体的なDB操作は業務の関心事に依存させることで、

DBの操作やテーブルレイアウトの変更などなどにサービスクラスが引きずられることなく、

業務の関心事とDB操作を完全に切り離せるこの考え方は重要だと思います。

業務の関心事中心で考え、それを実現するための具体的なDB操作は使う側(サービスクラス)

から隠蔽でき、使う側をシンプルに保てるのだろうなと思います。

ただ、、、名前だけのリポジトリは今まで見たことがあるけど、

こうやって正しくリポジトリを作っているケースは僕の経験した現場では見たことないです。

(だから保守開発でいつも火を吹いているのですが、、、)

サービスクラスでも部品とそれを組み合わせるという考え方を持つ

チェック〜登録〜参照で１つのビジネスサービスとなる場合、

これらを１つのサービスクラスで実現するのではなく、それぞれで個別のサービス、

さらにそれらをユースケースとしてまとめるサービスの２つに分ける。

このように本では述べられていました。

サービスクラスもユースケースサービス、個別サービスに分けるという考え方で整理していくと

サービスクラスのごちゃごちゃを防げるという考え方はドメイン駆動設計で勉強したことがありましたが、

やはり重要なのだと改めて認識しました。

また、

チェック〜登録〜参照の例で、

登録はチェックが行われた前提で設計をする。(契約による設計)

無茶苦茶な要求が登録に投げられる可能性を考慮して設計しない。(防御的プログラミング)

それによってシンプルな設計にできる。

このようにも本で述べられており、

ここも個人的には抑えておきたいポイントかなと思いました。

まとめ

現場で役立つシステム設計の原則第５章　アプリケーション機能を組み立てるを読んで、

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

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

今の時代ビジネスと共にシステムも成長させなければならず、

つまりシステムの改善や変更は当たり前(１発出して終わりではない)。

そんな中、今動けばそれでいいやという考え方で作ってしまうと後の保守開発でひどい目に遭う。。。

そういうことを踏まえてこの本の設計の考え方の重要性を、

一緒に開発するチームのメンバーにはインプットしていけたらなと思います。