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

はじめに

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

学んだことと今後現場で取り入れたいこととをまとめました。

 

システム設計、開発に一通り携わったシステムエンジニアやプログラマー

だいたい2〜3年目かな・・・に伝えたいような内容です。

(当時の自分にも伝えたかった)

 

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

 

1章

この辺りが基本的なところですがやはり重要ポイントだなと改めて気付かされました。

  • 変数名など名前をわかりやすくする(ぱっと見て分かるように)
  •  メソッドは短くクラスは小さく(使いまわせなくならないように)
  • 副作用をなくす(オブジェクトが意図せず変更されないように)

現場ではこの辺りを徹底させるようにしていきたいです。

この章の詳細はこちらの記事にまとめました。

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

 

 

2章

〇〇区分、〇〇種別・・・などが業務要件のなかで出てきて、

〇〇区分がこれでなおかつ、〇〇種別がこれの場合はこうするみたいなことは複雑になりがち。

それをどう整理するか??というテーマの章でした。

 

特に重要だと感じたのはこの辺りです。

  • 条件分岐は単文でなおかつ早期リターンで
  • 区分毎にクラスを分けてさらに多態にし、区分の違いをifを使わずに表現
  • 区分毎のロジックを列挙型で整理

 

区分毎にクラスを分けて多態を使ってさらに列挙型にちておいて複雑な分岐をなくしていく。

という考え方は僕の中になかったのですが、早速現場で取り入れてます。

この章詳細はこちらの記事にまとめました。

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

 

 

3章

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

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

 

特に重要だと感じたのはこの辺りです。

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

 

自分が設計をする際は、

業務データ+ロジックの置き場を整理していくイメージで

進めるようにしています。

この章の詳細はこちらの記事にまとめました。

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

 

 

4章

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

ドメインモデルの設計の進め方だったり、

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

 

特に重要だと感じたのはこの辺りです。

  • 業務を理解するための分析とソフトウェアを実現するための設計が一体になった活動がドメインモデルの設計
  • 業務で使われる言葉とクラスやメソッドを一致させる
  • ドメインオブジェクトを見つけるには業務の関心事の「コト」に注目する
  • ドメインオブジェクトは一度作って終わりではなく洗練させていくもの

 

業務を分析〜業務ロジックの置き場を整理〜作る

を何度も繰り返して洗練させていく作業をまさに今自分は現場でやってます。

やってみると、

作ってみてはじめてわかる事もあるという事が分かったり、

最初の分析でいきなり完璧に分析しきるのは難しいという事も分かりました。

この章の詳細はこちらの記事にまとめました。

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

 

 

5章

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

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

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

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

 

特に重要だと感じたのはこの辺りです。

  • サービスクラスがごちゃごちゃする原因はドメインオブジェクトが機能していないかDBや画面に振り回されるから
  • サービスクラスに業務ロジックを書きたくなったらドメインモデル改良の機会
  • データベースの具体的な操作と業務の関心事とを分けて考える
  • サービスクラスでも部品とそれを組み合わせるという考え方を持つ

 

ドメインオブジェクトを使う側のサービスクラスは常にシンプルに!!

を僕も最近は現場で心がけています。

この章の詳細はこちらの記事にまとめました。

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

 

 

6章

データベース設計における悪い設計と良い設計についてと、

ドメインオブジェクトとデータベース設計は別物として考えるべき

というような内容の話が中心の章でした。

 

特に重要だと感じたのはこの辺りです。

  • 悪いテーブル設計は取り扱う際の暗黙の知識が大量に必要
  • 事実を記録するのがテーブル設計の基本
  • ドメインオブジェクトの設計とテーブルの設計は別物

 

僕も現場で暗黙の知識が大量に必要なテーブルに遭遇することが多く。。。

すでに動いているシステムをテーブル設計から変更するのが大変なので

放置。

 

のようなケースは良くありました。

少なくとも今後新規で自分が設計するものはそういうことをしないようにしたいです。

この章の詳細はこちらの記事にまとめました。

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

 

 

8章

APIのインタフェース、1本のAPIの役割を大きくしすぎない工夫について述べられていました。

 

特に重要だと感じたのはこの辺りです。

  • アプリケーション間の連携パターン4つについて|ファイル転送〜API連携〜メッセージングなど
  • RestAPIはPOSTやGETを使いPUTやDELETEは極力使わない
  • 大は小を兼ねるAPIはAPI提供側・利用側共に不幸になる

 

大は小を兼ねるAPIは現場でよく見かけるので、

今後はそっちの方向に行かないように注意したいと思います!!

この章詳細はこちらの記事にまとめました。

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

 

 

9章

要求分析と設計を同じチームや人でやることのメリットについての

話が中心の章でした。

 

特に重要だと感じたのはこの辺りです。

  • 昔求められたものと最近求められるものとの違い
  • 要求分析と設計を1チームで行えば品質が上がり、ドキュメントが減らせ、開発スピードが上がる
  • 契約は準委任契約で、業務にも関心が持てるメンバーで体制を組めるとベスト

 

昔と今の求められていることの違いを理解し、

今求められていることに対して効率よく、品質よく開発を進めるための工夫としては何ができるのか??

を考えなければなとこの章を読んで改めて思いました。

 

この章詳細はこちらの記事にまとめました。

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

 

 

まとめ

本を読んで、

現場を、システム開発の設計〜製造〜テスト工程を経験して、

既存システムの課題にぶち当たったり、

新規システム設計の時の試行錯誤を経験した人がこの本を読むと

とても学びがあるだろうなと感じました。

 

この本を読んで実践できる人がシステムの設計をしてくれてたらどれだけ

保守開発楽だったかなと。。。。

 

自分自身、

現場で学んだことを取り入れたり、

現場の課題を本で学んだ視点で見つけて対策打ったり

しています。

 

自分の場合2〜3年目くらいにこれを読んでおきたかったなと、、、

 

コメントを残す

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

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