makopi23のブログ

makopi23が日々の生活で感じたことを気ままに綴るブログです。

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

2016/1/21(木) 「DDD Alliance! ドメイン駆動設計のためのオブジェクト指向入門」に参加してきました。

connpass
http://ddd-alliance.connpass.com/event/25209/

Togetter
http://togetter.com/li/928734

場所は株式会社ドワンゴさんです。
参加者は100人弱でしょうか。私は抽選はハズレてしまったのですが、キャンセル出たおかげで繰り上がりました。

以下、個人メモ。



ドメイン駆動設計のためのオブジェクト指向入門 from 増田 亨


■ ドメイン駆動設計
  • ドメイン層のソフトウェア設計の話。ベースはオブジェクト指向。
  • オブジェクト指向の場合はドメインの理解とプログラミングの距離が近いと思っている。
  • 1~3章に原則が書いてある。それ以降はその原則をどうやっていくか、知見が書いてある。
  • ドメインモデルが1~3章のキーモデル。
  • ユビキタス言語の中でも特に重要な関心事を集めたのがドメインモデル。ユビキタス言語のサブスタック。
  • 2章でコミュニケーションを重視しているということは、アジャイルの考えに近い。
  • 3章の「モデルと実装を結びつける」ことによって、オブジェクト指向が求めてる生産性とか変更容易性が生まれてくる。
  • クラスを発見する人間と分析する人間が一緒となるという考え方。
  • コードを書く人が分析して書けばいいんじゃないか。

■ ドメインの隔離
  • ドメイン層を独立させて、学んだことをいかにここに書くか。
  • ドメイン層は他の層を見えてない。他の層がドメイン層を参照する。

■ オブジェクト指向: コードの整理

  • クラス単位にコードを整理する。
  • 主要な関心事の単位にクラスを作る。顧客とか。

■ オブジェクト指向:アーキテクチャ

  • 変更のコストを下げることによって、変更をあたりまえにする。
  • アジャイルとオブジェクト指向は一体。

■ 独自の「型」を設計する

  • 独自の型 = 利用者の関心事
  • 基本データ型 = コンピュータの関心事

■ 契約による設計

  • バートランド・メイヤーの本を読んで、「契約による設計」っていうのを理解した。
  • それをベースに考えると、他のもわかるようになってきた。
  • エリック・エヴァンスも契約による設計をベースにする、と本に書いていた。

■ 実装手段(how)を隠蔽する

  • メソッドの引数とか戻り値にJava言語仕様の型(StringとかLocalDate)とか使われてたら、それは改善すべき。

■ メトリクス

  • 1つのアグリゲートでオブジェクトが10くらいぶら下がっている。

■ 参照オブジェクト vs @Entity
  • ドメイン駆動設計における「エンティティ」というのは、参照オブジェクトのこと。JPAの@Entityとはまったくの別物。
  • テーブルというのは業務の関心事とは一致しない。
  • 基本型が見えちゃうので、JPAはドメイン駆動設計とは必ずしも相性良くない。
  • なのでMyBatis使ってる理由でもある。

■ オブジェクト指向設計の学び方

  • まずはやってみる(コードを書く)
  • 上2冊は鉄板のおすすめ



実装パターン
実装パターン
posted with amazlet at 16.01.24
ケント・ベック Kent Beck
ピアソンエデュケーション
売り上げランキング: 134,260


■ 質疑応答
Q1.
トランザクション周りで、集約をまたいじゃった時、どう解決するのか

A1.
今回の講演では割愛した部分に対する質問ですね。
私はアンチトランザクション派なので、トランザクション組まない。小さく分解していく。
注文と注文明細を考えるとき、大きいのガツンと保存するんじゃなくて、小さく注文明細ごとに書き込む。

Q2.
ドキュメントを残さないようにするという話があった。システムが大きくなると、ドキュメントを残さずにやるにはどうすれば。

A2.
ドキュメントは書かないわけじゃない。必要なときに必要なドキュメントを作る。
でも、長期メンテするものではない。一切メンテしない。
正しくて最新なのはコードだけ。

Q3.
リポジトリからデータ取得するとき、戻り値の型で、商品を例にするとIDとか商品名とかがある。
findメソッド使う場合、商品自体がオブジェクトとして帰ってくるが、商品名だけほしい場合はどうする?

A3.
商品リポジトリから必要なものだけとってくる。業務的に本当に必要なら。

Q4.
プリミティブを隠蔽して表現力高めるのはいいと思うが、コンストラクタのnewも丸出しは良くないと思うがどうか。
C言語のmallocみたいに感じる。

A4.
コンストラクタは隠したほうがいい。
フレームワークがDBからデータを取ってきて作ってくれるし、ファクトリが作ってくれたりするようにする。

Q5.
DDDで構築したとしても、ドメインが変化していくスピードが早すぎてコードが追いつかない場合はどうすれば。

A5.
オブジェクト指向のスキルを磨くこと。
ビジネスががらっと変わるよりも、ビジネスをやりながら徐々に分かってきて商売を変化させていく時は、DDDで商売を捉えられていたら、商売とシステムの変化の速度はそれほど変わらないはず。
スピードが出ないなら、オブジェクト指向とか設計とか商売の構造が捕まえきれてないのでは。
そもそもリアルな商売の変更も、コストと時間はそれなりにかかる。

Q6.
ビジネスの市場が未成熟でドメインエキスパートもビジネスを理解しきれてない場合、どういうアプローチができるか?

A6.
ドメインエキスパートは、安定した業界でもいない。なので自分から提案してキャッチしにいかないといけない。
ソフト開発者はそのビジネスの一人としてビジネスを一緒に考えるくらいじゃないといけない。

Q7.
プリミティブ型ではなく独自型を使う利点はわかったが、フレームワーク使う場合は妥協点を見つけないといけない。
MyBatis使ったとのことだが、苦労しなかったか。

A7.
値オブジェクトの中には基本データ型がある。
MyBatisはsetterなくてもやってくれるが、SpringのORMはsetterないとうまくやってくれなかったりする。
そのへんは妥協。


★感想:
増田さんのお話を聞いていて思ったのは、増田さんが自らDDD講演の場に身を置く機会を設けることで、増田さん自身がDDDの新たな知見を貯めこんでいっているのでは、ということでした。
講演の中でもおっしゃってましたが、「本を何度も読みなおすことでいつも新しい発見がある」と。
あの鈍器に匹敵する本を何度も読みなおすというモチベーションと労力は、並大抵ではないと思う。
それをあえてやっていのも凄いし、それを毎回、スライドに自分の言葉で纏め講演することで、さらにDDDの知見を深めているのだと思う。
そしてその知見を惜しみなく勉強会で提供する。OSSに通じるものがありますね。感謝。

スライドの中で、ControllerクラスをPresentation層として表現していましたが、これって一般的なのかな?
私はApplication層くらいかな、と思ってました。Presentation層って、Viewのイメージなので・・・

増田さん、関係者の皆様、ありがとうございました。
関連記事
スポンサーサイト

コメント

コメントの投稿


管理者にだけ表示を許可する

トラックバック

トラックバック URL
http://makopi23.blog.fc2.com/tb.php/198-8f47c08d
この記事にトラックバックする(FC2ブログユーザー)

FC2Ad