エンジニア的なネタを毎週書くブログ

東京でWebサービスの開発をしています 【英語版やってみました】http://taichiw-e.hatenablog.com/

増田亨さん　ドメイン駆動設計の正しい歩き方　を聞いてきました #bpstudy

設計

BPStudy#141〜DDD(Domain Driven Design)実践の現場 - connpass　に行ってきました！

特に心に残ったことまとめ

  • DDDは、「ソフトウェアの変更を楽で安全にする」ことに振り切っている。
    • 逆に言えば、変化がないソフトウェアには最適ではない設計かもしれない。
  • コアドメインに集中する。真のコアのみを切り出して、そこに集中する。
    • 例えば、すべてをバリューオブジェクトとエンティティでやろうとするような試みは失敗パターン。
  • モデリングとコーディングは行ったり来たり。いかに行ったり来たりするかが大事。
    • 仮設を立ててコードを書いてみる。「軸」の候補が3つあるなら3つ書いてみる。「こんなの数時間書けばわかる」！！

以降、ノート

言葉の使い分け：ビジネスロジック vs ドメインロジック

  • 「ビジネスロジック」は、そもそものビジネスのルール。ソフトウェアかどうかは関係ない。（ITを使っていないビジネスはいくらでもある）

それに対して

コアドメインに集中する

DDDは「『核心にある』複雑さ」に立ち向かうためのもの。ソフトウェアすべてを設計の対象とするのではなく、コアに集中する。
コアを切り出して集中することで、不思議と周りも綺麗になっていく。

例えばホテルの予約サイトなら…

全体の中でも、特にコアとなるビジネスロジックは料金計算。*1*2


コアドメインを独立させる。独立とは、 ここだけで開発できて、ここだけでテストできる状態にすること。画面の要素やデータベースのテーブル定義は一切入り込まない。
独立させたら、特徴を掴むためにモデリングする。自然言語も使って良い。

この段階でのモデルはあくまで「仮説」。仮説を確かめるために、コードを書いてみる。

すると…
コーディングしづらいなどの問題が見つかることがある。

その場合、「モデルにフィードバックする」。
コーディングしづらいのは、モデルが適切でないのかも。モデルを更新し、再度、コーディングを試してみる。

…というように、モデルとコードを行ったり来たりすることが重要！！

そして、このモデルは実装のために作っているので、必ずしもきれいにならないことも多い。*3


コアドメインが複雑なのであれば、その中でもさらにコアを探す。
何が中核なのか。
「幼児の寝具」ではないだろう。

シーズンか、一室何名か、特別室／一般室か。
どれがコアなのかわからなかったら、3つそれぞれを軸にしたコードを書いてみる。
数時間書けばわかるはず！！*4

ビジネスを継続的に学ぶ

よくある失敗の一つが、「ビジネスを表面的に捉えて理解した気になる」。
もし深く理解できていれば、例えばサンプルの計算結果のタイポに気づけるはず。
あるいは、書かれていない部分の計算結果がわかるはず。

更に、周辺のビジネスの理解は重要。
どんな背景があるのか。
周りが分かってくると、コア部分で何を作らなければならないかがまた見えてくる。*5

エヴァンス本の読み方

読み方のコツ*6が有る。

他の方のレポート

*1:まさに「ホテルの予約サイト」の「料金計算」を主の生業として数年やってきた人間なので、このお題の登場にはビックリ

*2:検索や予約はコアではない…　は私が言ったんじゃなくて増田さんの言葉ですからね！

*3:実装のためでない、ビジネスの理解のためのモデルにも価値がある。ただし実装には貢献できないかもしれない。これらは切り分けて考える

*4:これが今回一番心に刺さったフレーズなのです

*5:これ、よく私言ってるのですが…　エンジニアはビジネスの背景をきちんと理解し無くてはならない。今の私達の現場は人数が増えてきたので、ポジションが別れている。高度なサッカーで11人がボールに群がっていくことはないはず。一方で、11人それぞれが、自分のポジションのことだけでなく、他の10人がどんな意図でどんな動きをしているのか理解できなければ、チームプレーはできないはず！

*6:・冒頭、「突然わけのわからないストーリーが始まる」ので、はじめは読み飛ばすべし ・結構な前提知識が必要 ・文章の構造を捉えつつ、重要なところだけ読む ・文章に癖があって読み方のコツが必要 という説明を聞いて、「それ普段、お仕事で読んでいる某文章と全く特徴が同じなんですけど…」　と思った次第。大事なことが書いてあるけど読みにくい文章の読み方って共通点があるのかな。