読者です 読者をやめる 読者になる 読者になる

はむはむエンジニアぶろぐ

このブログのコンセプトは"ハッキングの為なら愛する家族を傷つけることをいとわない" 自分にとってエンジニアリングは "手段ではなく生きる目的" である

DDD Alliance! ドメイン駆動設計のためのオブジェクト指向入門に参加してきた

DDD 勉強会

2016年1月21日に開催されたドメイン駆動設計のためのオブジェクト指向入門に参加してきました。

その時のスライドがこちら

www.slideshare.net

発表内容のメモを残しておく

私のDDDに対する解釈が、混じったメモになります。

DDDは、インクリメンタルな設計である。
ドメインに対する理解(ベース)をもとに、オブジェクト指向で表現する。
ドメインモデルとは、ドメインの知識を鋭く解説する。
ドキュメントで、長ったらしく解説するより語彙が大事。


モデルと実装は結びつけろ。

  • 開発の生産性
  • 変更容易性

が、もたらされる。


日常で使われる言葉をコードで体現する。


ドメインを分析する人と実装する人が別れてはいけない。
ドメインを分析する人がコードを書き、コードを書く人が、ドメインを分析する。
クラスを作るためには、分析が必要。
分析者と実装者は、離れるな!!
保守するときは、分析者なんていないはず。
じゃあ、設計段階からそうすればいい。


ドメインエキスパートや技術者と話をし理解してコードで体現すれば、ドキュメントは殆どいらない。
「毎日、分析し、毎日、コードを書く」を実際に実践してみると、クラスがどんどん表現豊かになっていく。
ドメインを学び学んだことをコードで表現する。


ドメイン層のオブジェクトを設計する場合は、加工・計算を隠蔽し業務の加工・計算を表現。
プリミティブ型は、無ければない方が良くドメイン独自の型を作る。


クラス単位に関連するコードを整理する。
そうすることで変更が、あちこちに飛び火しない。
アルゴリズムとデータはセット。
機能クラスとデータクラスを分けてはいけない。
機能クラスとデータクラスを分けるのはアンチパターンで、変更が飛び火してしまう。
そうしてしまうと、どこからでもドメインロジックをかけてしまう状況になる。
そうなると、変更コストは減らない。
判断、計算はドメインオブジェクトがやろう。


集約(アグリゲート)を作ろう。
例えば、

  • 顧客アグリゲート
  • 注文アグリゲート
  • 商品アグリゲート

各アグリゲートは、root(顧客など)の下に関連クラスを抱える。
各アグリゲート単位に、分析して実装する。
各アグリゲートに知識やルールを集約する。
強く関連する部品は、アグリゲートにする。


独自の「型」を設計しよう。
メソッドの引数とか、戻り値も独自の型を使用するようにする。
利用者の関心事を表現できる。
プリミティブ型は隠蔽しよう。積極的に使うべきではない。


オブジェクトとオブジェクトが協力して仕事をする。
契約による設計
DDDは、契約による設計をベースにしている。
契約上必要なことを知っていればよくて、相手に踏み込んではいけない。

  • ドメイン層は独自の型だらけにする
  • 独自の型=利用者の関心ごと
  • 基本データ型=コンピュータの関心ごと

契約による設計のメタファーの伝わりやすさは、現実世界の契約を知らないと伝わらない。


実現手段(How)を隠蔽する。
DBから取得するのか、キャッシュから取得するのかそんなことに興味はない。

リポジトリは、アグリゲートを取り出す仕組み。
業務知識があれば、各アグリゲートのコードを見れば理解できる。


ドメインオブジェクトは、「良い部品」である。
値オブジェクトで、明示的に制約をかける。
何文字以内、何日から何日まで、100以下までなど。
完全コンストラクタで不変にする。
不変にすることで、setterがなくなる。
ドメインエキスパートとの会話の中で、ドメインオブジェクトを作っていく。

質問してみた

DDDを実践していく中で2点、課題に思っているところを質問してみた。

Q1

成長するドメインに対して実際のコードが追いついていない。追随するためには、どうすればよいか?

A1

オブジェクト指向のスキルを磨く。
変更を強くする設計を学んでいく。
ビジネスが、ガラッと変わることはない。
しっかりと、ビジネスを捉えていればギャップは起きない。
今の設計が、ビジネスを捉えきれていない。

感想1

たしかにその通りである。
今の設計がビジネスをとらえた設計になっていない。
私がメンテしているコードは、10年以上も前のコードで、ハッキリ言ってドメインが腐っている。
そこまで、いくとリプレイスレベルだと思う。

ただ、新規開発に携わることもありその場合は、CIやテストに力を入れ変更に対するストレスが無い状況を作り上げていくのが大事だと思った。

Q2

新規市場など、そもそもドメインが未成熟でドメインエキスパートもドメインに対する理解が足りない場合、どうすればよいか?

A2

そもそも、ドメインエキスパートが何でも知っていると思わないほうがいい。
何でもかんでも知ってるドメインエキスパートはいない。

我々、エンジニアがビジネスに関わっていくという役割をもつ。意識を持つ。

感想2

これを聞いて、打ちのめされた。
自分自身が、ドメインを定義していくという意識が欠如していた。

正直 私は、ビジネスの話が得意ではないし好きでもない。
だがしかし、息の長いシステムを作るためには必要な意識であり行動である。

とはいえ、ドメインが未成熟ということは、安定性はなく今後もそのドメインが存続するとは限らない。
システムを作る際は、作り混みすぎず早くリリースまで持っていくという設計判断も磨かなくてはならない。