BPStudy#141〜DDD(Domain Driven Design)実践の現場に行ってきた #bpstudy

BPStudy#141〜DDD(Domain Driven Design)実践の現場に行ってきました。簡単に所感をまとめます。

bpstudy.connpass.com

所感

最近、価格計算のロジックを実装する機会があり、個人的にはなかなかホットな内容でした。とはいえ、自分の場合は特にドメイン駆動設計という感じではなかったのですが、価格計算のロジックはアプリケーションのレイヤから分離するようにしました。で、今回の話を聴く限りではこのアプローチ自体はあまり間違いではなかったのかなとなんとなく実感を得られました。

あと、モジュールやメソッドの切り方を考えるときに個人的に意識していることはテストがやりやすいかどうかということ。特に、モックを多用せず、シンプルにテストコードが書けるかどうかは重要かなと思っています。なので、今回の事例として挙げられていた「料金計算ロジックをどうやってコードで表現するか」ということに関して、テストがやりやすいかどうかという観点で考えるのは割とありなのかなと思っている今日この頃です。

そういえば、増田さんの本は読んだことがあるけど、エヴァンスの本は手が出しづらくてまだ読んでない...。そろそろ読んでみるか。

現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法

以下、メモから抜粋。

ドメイン駆動設計の正しい歩き方~どこに焦点をあわせ、どう実践するか

www.slideshare.net

  • ドメイン駆動設計はアーキテクチャや設計に限った話ではない
  • ソフトウェアの核心にある複雑さに立ち向かう
  • 複雑さはビジネスの複雑さに起因する
    • 複雑になる要因はたくさんある
  • ビジネスルール
    • 制約や約束事 (システムやITは関係ない)
  • ドメインロジック
    • ビジネスルールをシステムやソフトウェアとして実現するもの
  • 核心にある複雑さを適切に扱う
    • 周辺の複雑さが整理される
    • 条件分岐を外に抜き出すと入出力は単純になるはず
      • 分岐が散在するから複雑になる
    • 全体の構造が改善する
  • ドメイン層を独立させる (アーキテクチャの話)
  • ビジネスの活動を継続的に学ぶ☆
  • コアドメインに集中することにどれくらい時間を費やせるかがポイント☆
  • 個人ではなくチームの基本方針としてやっているか☆
  • 全体を均質にやるのではなくポイントを絞って深掘りする
    • 複雑なものを整理して単純なIFで使えるようにする
  • ドメイン層に入出力の関心事(画面やテーブル)を持ち込まない
  • モデルと実装は切り離さない
    • 実装のためにモデリングする
    • コードをうまく書くにはどのようにモデルを整理すればよいかを意識する
  • 例) 複雑な料金計算ルール
    • ドメインロジックを独立させる
    • 画面やDBのことを一緒に考えない
  • モデルで整理してモデルと実装を密に結合する
    • ルールを整理する
    • モデルで仮説を立ててコードで実現してみる
    • コードのリファクタリングとモデルへのフィードバックを繰り返して改善する☆
  • コアドメインに集中する
    • ある軸を選んで簡単なコードを書く、別の軸で簡単なコードを書く☆
    • 実験することでモデルの妥当性を検証する
    • 中核のルール、周辺のルール、除外すべきルール
  • ビジネスを深く洞察する
  • システム間の秩序の改善を続ける
    • 連携するシステムや人間を意識する
    • どのようにデータを持つべきかがわかってくるはず
  • ドメイン駆動設計を現場に導入する
  • ドメインエキスパートがちゃんと説明してくれるとは限らない
    • 具体例を提示して質問する
    • あえて間違っていることを質問して語ってもらうのもあり
    • バックオフィスの人の方がルールを知ってるかも (経理のベテランや営業支援スタッフとか)

教材セット

www.slideshare.net

モデル駆動型開発によるビジネスをソフトウェアに落し込む1つのやり方

  • モデリング
    • モデルを作ることで分かりやすくする
  • ビジネスとソフトウェアは乖離する
    • モデルを中間成果物としてビジネスとソフトウェアを繋げる
  • モデル駆動型開発(MDA)
    • CIM, PIM, PSM, CODE ☆
  • 言語の抽象度は上がっている
    • プラットフォームの複雑さから分離する
  • モデル駆動開発のいいところ☆
  • 言葉を共有
  • 言葉の乖離
    • ドメインエキスパート⇔開発者
    • 開発者による抽象化は設計の支えにはなるがドメインエキスパートには理解されないかも
  • ユビキタス言語
    • モデルを言語の骨格とする
    • コミュニケーションとコードではその言語を用いる
    • 用語集とは違う
    • 形式知として全体に浸透するもの☆
  • わからない言葉を整理してビジネスの外観を捉える
  • 言葉を整理する中で気をつけるポイント☆
  • トランザクションスクリプトになりがち
    • 関心事が入出力に寄ることでドメイン層がただの入れ物になる
    • テーブル設計から入るとドメインがデータの器になりがち
    • ビジネスルールが書かれていない
  • どこにビジネスルールを書くか
    • 育てる