銀行員からのRailsエンジニア

銀行員からのRailsエンジニア

銀行員から転身したサービス作りが大好きなRailsエンジニアのブログです。個人で開発したサービスをいくつか運営しており、今も新しいサービスを開発しています。転職して日々感じていること、個人開発サービス運営のことなどを等身大で書いていきます。

【技術書まとめ31】現場で役立つシステム設計の原則

こんにちは。

今回は、DDD(ドメイン駆動設計)を学ぶために、勤めている会社で話題になっていた「現場で役立つシステム設計の原則」を読みました。

学ぶことが多く、今後も定期的に見返したいと思ったので、ポイントをまとめました。 

f:id:ysk_pro:20210707081045p:plain

設計の重要性

  • どこに何が書いてあるかを分かりやすくし、修正や拡張が楽なコードを生み出すこと
  • 変更が大変なプログラムの特徴 3点。どれも関心事の詰め込みすぎが原因
    • メソッドが長い
    • クラスが大きい
    • 引数が多い

 

設計の仕方の比較

2つの設計の仕方を比較します。

どちらの設計も、関心事の分離のために 3層アーキテクチャ を使うことを前提にしています。

  • プレゼンテーション層:UIなどの外部との入出力
  • アプリケーション層:業務機能のマクロな手順
  • データソース層:データベースとの入出力

 

データクラスを使う設計

  • 従来の手続き型の設計で基本とされていた、データを格納するデータクラスと、ロジックを記述する機能クラスに分ける設計
  • データクラスは getter/setterメソッドだけを持ち、データを使った判断/加工/計算のロジックは、機能クラスに記述する
  • 3層が同じデータクラスを参照できる結果、データクラスを使うロジックが3層のどこでも書けてしまい、重複しやすくなってしまう欠点があった

f:id:ysk_pro:20210706082357p:plain

イメージ図(本書のCHAPTER3 図3-2をベースに作成)

 

ドメインモデルを使う設計

  • ドメインモデルとは、業務で扱うデータと関連する業務ロジックを集めて整理したもの
    • ドメインとは、業務アプリケーションの対象領域を指す
  • ドメインモデルを使った設計では、ドメインモデルに集めた業務ロジックを3層が利用する形になる → 業務ロジックを書く場所が明確になり、重複を防げる

f:id:ysk_pro:20210706083139p:plain

イメージ図(本書のCHAPTER3 図3-4をベースに作成)
  • 業務ロジックを記載するのはドメインモデルのみとすることで、3層の記述は簡潔で分かりやすくなる。業務アプリケーションのコードが複雑になる理由は、業務ロジックの複雑さであるため
  • ドメインモデルは画面やデータベースの都合からは独立して、純粋に業務の観点から業務ロジックを整理できる → ドメインモデルを見れば、業務全体がどういう関心事から成り立っているかを理解できるようになる

 

ドメインモデル設計の仕方

ドメインモデルを使う設計の利点を理解した後は、実際にどのように設計を行うかを学びます

  • ドメインモデルの設計は、業務で使われる具体的な用語(概念)を手がかりに進める。その用語が、データとロジックをひとかたまりとしてプログラミング単位として使えるかを検証する
  • 部分に注目し、個々の部品を作り、それを組み合わせて段階的に全体を作っていくボトムアップのアプローチを取る
  • 部分に注目するが、全体像を意識しないと間違った方向へ進む危険がある。全体を俯瞰する道具として、以下の2つがある
    • パッケージ図
      • パッケージ間の依存関係を表現する
    • 業務フロー図
      • 業務の活動を時間軸に沿って図示したもの
      • 顧客/販売部門/出荷部門などの活動の主体ごとのレーンを並べ、その間の情報のやり取りを表現する
  • これらの図で全体を俯瞰したら、重要な部分を探し、重要な部分から作っていく
  • 業務を分析し、理解するために、業務の関心事をヒト/モノ/コトの3つに分類する手法がある
    • ヒト:人の意思/判断/行動についてのデータを持ち、そのデータを使った判断/加工/計算のロジックを持つ
    • モノ:ヒトが業務を遂行するときの関心の対象。これらの属性を表現するデータと、そのデータに対して業務的にどういう判断/加工/計算をしたいかをロジックとして持つ
    • コト:基本的にヒトの意思決定や行動の結果。業務アプリケーションの基本的な関心事は、コトを記録して、コトの発生を通知すること。コトに注目すると、全体の関係整理しやすい

 

ドメインモデル設計の注意点

  • 業務では実際に使っていない抽象的な言葉をクラス名として使ってしまうと、そのクラス名は具体的には何も説明しておらず、業務を的確に捉えられない
  • オブジェクトとテーブルを自動的にマッピングするアプローチは、どちらかの設計のアプローチの制約を受け、うまくいかないことが多い。業務ロジックはオブジェクトで、事実の記録はテーブルで行うべき
  • 表示のためのロジックと業務ロジックを混在させない
    • 例1)一定金額を超え、かつ、注文後1日以上経過した注文を画面で強調表示する場合、画面表示のロジックに if 文を書いてしまうことがあるが、これは業務ルールなのでここに書かない方が良い
    • 例2)カンマや千円単位の表示なども、ドメインオブジェクトが持つべき加工ロジックの候補。データの文字列表現は、利用者の関心事であり、そういう関心事に関わる加工や判断のロジックはできるだけドメインオブジェクトに集約した方が変更が楽で安全になる

 

おわりに

ここまで読んでいただきありがとうございます。

これまで DDD(ドメイン駆動設計)の本を何冊か読んできましたが、個人的には本書が一番理解しやすかったです。本書をとっかかりにして、関連書籍を読んでいき、実践することで DDD への理解を深めていこうと思います。

本書の中では、図を多く使って丁寧に説明されていて理解しやすかったので、ご興味ある方は是非読んでみてください。