重要だと感じたポイント、気付き、今後参考にしていくべきだと感じたことをまとめてみました。今後現場で取り入れたいこと、気付きなどなどまとめ記事を作ったので是非こちらも見てください!!現場で役立つシステム設計の原則から学んだことや気づきまとめ現場で役立つシステム設計の原則第5章を読んでの気付きなど5章はドメインモデルで設計したドメインオブジェクトを組み合わせて、1つの業務サービスを実現するアプリケーション層のサービスクラスを作る際、なぜごちゃごちゃしがちなのか??その対策としてどういう設計思想が重要なのか??についてまとめてある章でした。DB操作と切り離す、画面と切り離すという考え方とそのやり方については個人的には、プログラマー2年目くらいの自分に聞かせたい・・・思える内容でした。サービスクラスがごちゃごちゃする原因はドメインオブジェクトが機能していないかDBや画面に振り回されるからまず、アプリケーション層のサービスクラスはドメインオブジェクトを組み合わせて1つの業務サービスを実現する役割を担います。このアプリケーション層に作るサービスクラスは、ドメイン層のビジネスロジックを使ったり、データソース層のDB登録、検索を使うだけで1つのビジネスサービスを実現したい。画面用のデータ加工(1,000を1,000円に変換など)したり、DB操作を手続き的にごちゃごちゃ書いたりなどなどしてしまっていることが多いです。(実際僕が経験した現場でごちゃごちゃしていないサービスクラスを見たことはないです)これらの原因として、ドメインオブジェクトがビジネスロジックの置き場として機能していない。画面レイアウトやDBのテーブルレイアウトに振り回されている。これらが原因として考えられると本では述べられていました。入り組んだ条件分岐をサービスクラスに書く必要はなくなり、DB操作の具体的な実装をサービスクラスから切り離すことができれば、テーブルレイアウト変更などにサービスクラスが影響を受けることはなくなるはずです。(最初からその設計思想でスタートできていないシステムが多いから保守開発で困ってるのですが、、、)動かすだけならサービスクラスにサクッと分岐や一部ビジネスロジックを書いてしまった方が楽。動かすだけならサービスクラスに分岐や業務ロジックを書くのが簡単だが、サービスクラスに安易に業務ロジックを追加すると同じように別のサービスクラスにも業務ロジックをかくことになる。ドメインオブジェクトを追加するか改善の方向で修正を行うべき。このような内容が本では述べられていました。その通りだなと・・・・サービスクラスの設計の際に大切にしたい考え方の1つだと思います。業務的な関心事との間に差がでてきて、業務的な関心事が薄れてくる。業務仕様の変更に伴うプログラムの影響範囲が不自然な波及を生むことを表しているというのが自分の理解)その対策として、リポジトリに業務的な関心事をインタフェースで表現し、その実装としてデータベースの具体的な操作を分けて実装する。いう内容が本では述べられていました。業務の関心事とDB操作を完全に切り離せるこの考え方は重要だと思います。業務の関心事中心で考え、それを実現するための具体的なDB操作は使う側(サービスクラス)から隠蔽でき、使う側をシンプルに保てるのだろうなと思います。名前だけのリポジトリは今まで見たことがあるけど、こうやって正しくリポジトリを作っているケースは僕の経験した現場では見たことないです。(だから保守開発でいつも火を吹いているのですが、、、)サービスクラスでも部品とそれを組み合わせるという考え方を持つチェック〜登録〜参照で1つのビジネスサービスとなる場合、これらを1つのサービスクラスで実現するのではなく、それぞれで個別のサービス、さらにそれらをユースケースとしてまとめるサービスの2つに分ける。このように本では述べられていました。サービスクラスもユースケースサービス、個別サービスに分けるという考え方で整理していくとサービスクラスのごちゃごちゃを防げるという考え方はドメイン駆動設計で勉強したことがありましたが、やはり重要なのだと改めて認識しました。登録はチェックが行われた前提で設計をする。(契約による設計)無茶苦茶な要求が登録に投げられる可能性を考慮して設計しない。(防御的プログラミング)それによってシンプルな設計にできる。このようにも本で述べられており、ここも個人的には抑えておきたいポイントかなと思いました。普段から意識して現場での作業をしていこうと思います。サービスクラスがごちゃごちゃする原因はドメインオブジェクトが機能していないかDBや画面に振り回されるからサービスクラスに業務ロジックを書きたくなったらドメインモデル改良の機会データベースの具体的な操作と業務の関心事とを分けて考えるサービスクラスでも部品とそれを組み合わせるという考え方を持つ今の時代ビジネスと共にシステムも成長させなければならず、つまりシステムの改善や変更は当たり前(1発出して終わりではない)。そんな中、今動けばそれでいいやという考え方で作ってしまうと後の保守開発でひどい目に遭う。一緒に開発するチームのメンバーにはインプットしていけたらなと思います。コメントをキャンセルメールアドレスが公開されることはありません。コメントデータの処理方法の詳細はこちらをご覧ください。