重要だと感じたポイント、気付き、今後参考にしていくべきだと感じたことをまとめてみました。今後現場で取り入れたいこと、気付きなどなどまとめ記事を作ったので是非こちらも見てください!!現場で役立つシステム設計の原則から学んだことや気づきまとめ現場で役立つシステム設計の原則第4章を読んでの気付きなど4章ではドメインモデルの設計の進め方についてメインで書かれていました。業務知識の整理のやり方などなどについて説明されていた章でした。業務を理解するための分析とソフトウェアを実現するための設計が一体になった活動がドメインモデルの設計ドメインモデルの活動では分析と設計は一体になった活動。知識が増えてくるに従ってクラスやメソッドの内容が充実する。業務を学びながら早い段階でコードを書き、コードを段階的に成長させていく。そのため分析と設計は同じ人が実施するのが良い。このような内容の記載が個人的には印象に残りました。現場でたまに見かけるのが、、、自分はアプリアーキテクトだ!!細かい業務知識なんか知らん。業務の分析を行おうとしない人が無責任に手を出してへんな共通化して部品作って、、、こうやってできた基盤に乗っけて実際に業務要件を取り入れて開発していくと、この基盤なしで開発させてもらえないかな。思うような経験が大手の通信事業会社に開発委託として参画したときありました。業務を正しく分析して設計するのが普通だ。いうことが過去参加した勉強会でも話がでていました。興味がある方はこちら参照ください。変更の影響するソフトウェアの範囲が変更が関連する業務の範囲と一致する。いう内容が印象に残っています。業務で登場する概念をデータモデルクラス+機能クラスで実装していていろんな箇所でその業務ロジックの一部ロジックを持って影響範囲が大きくテスト工数も大きくなる。いうケースは今までの保守開発の経験の中で何度も体験しました。業務で登場する概念を細かい部品に分けてそれを組み合わせて1つの業務を実現する。部品は業務全体で使いまわせるようにする。ように設計できていれば今までの残業時間や変更の危険に伴うドキドキを減らせたことか。業務ロジックをどこに置くのか??を明確にするために当たり前だけど重要だよなと思いました。興味がある方はこちらご覧ください。「コト」の時間的な前後関係(先にAのコトが起きて、Bのコトが起きた後にCのコトが・・)があったり、コトには「ヒト」と「モノ」との関係があったり、このあたりの関連する業務ロジックやドメインオブジェクトを発見する糸口となる。いう記載がありました。部品としての使い勝手を確認しながら改善を続ける。改善を続けることで、プログラム全体のわかりやすさと、変更の容易性をさらに向上できる。この内容も自分の中では印象に残っています。僕も普段から意識しています。使う側が複雑になるとそれはドメインオブジェクトの方へ複雑な処理を移したほうがいいかも。業務の分析〜設計〜製造のサイクルを回す際に、ここの意識をもつことが重要だと感じました。普段から意識して現場での作業をしていこうと思います。興味がある方は実際に本を読んで自分自身で本に書かれてある考え方と自分の考え方を比較してみると面白いと思います。コメントをキャンセルメールアドレスが公開されることはありません。コメントデータの処理方法の詳細はこちらをご覧ください。