DDDと私


最初に

こんにちは moai です。
この記事は、ドメイン駆動設計 #1 Advent Calendar 2018 の7日目です。

昨日は、@kawakawa さんによるドメインオブジェクトとユースケースの関係についてでした。
今回は私とDDDの話をしようかなと思います。

ここでは、手法の話はしません。
手法の話をご期待の場合は、ご期待には沿えませんので、どうぞこちらでおかえりください。

DDDとの出会い

私がDDDに出会ったのはおおよそ二年前のことでした。
Amazonの購入履歴を見るに、わたしは2016/02/21にエリック・エヴァンスのドメイン駆動設計を買ったようです。

しかし、その時は第一部を読んで満足したような気がします。
ざっくり言うと良さがあんまりわからずに、途中で読むのをやめちゃったんですね。

だって、分厚いんだもの。

そのころ、私は新規開発をたくさんするようになったものの、
CRUDに非常に近い機能を作っており、 DBにうまく値を格納するかに熱心でした。

例えば、あるテーブルのデータをPDFに乗せるとか、
テーブルのデータを使って一覧画面をつくりソートするとかですね。

PDFにデータ載せて、こんなの作ったり、


一覧画面を作ったり。(これは弊社の今の画面なので、とても奇麗ですが昔はもっとおぼこい感じでした。)




そのため、そのころ読んでいたのはData Modeling Resouce Bookという
世の業務アプリケーションで使われているモデリングはこうなっているんだよという本を熱心に読んでいました。

そのころ思っていたこととしては、 うまくテーブル設計できていれば、
モデルの設計はあとからちゃんとついてくると信じていました。
何なら、DDDなんか知らなくても、俺は俺の最強のアプリケーション作れると信じていました。
そして、なんなら英語の本まで参照しちゃう俺すごい、くらいに思っていました。

今思うと、それは正しい局面もあれば、少し複雑になると正しくない局面もあると教えてあげたいですね。

若さ。

そんなこんなで私はDDDと出会いはするものの、
すぐに興味をなくし、
データモデリングという違う技術にご執心でした。

DDDに近づく。オブジェクト指向に興味を持つ

それからしばらくデータモデリングに触れなかったのですが、
機能をいくつか開発していくにつれて、
オブジェクト指向に興味を持つようになりました。

なんでかというと、段々と機能も複雑になってきて
概念を整理しながら作る必要が出てきたからです。

とくにデータだけではなく、モデル同士の相互作用が増えてきており、
その相互作用をどのように取り扱うのかというのを考えなければならなくなってきたからです。

幸いにもRubyには『オブジェクト指向設計実践ガイド』というオブジェクト指向の名著があり、それを読んで非常に感動していました。

ただ、ここで私は思ったのです。

オブジェクト指向、むずくね?

カプセル化、うん、わかる。
単一責任原則、うん、わかる。
ポリモーフィズム、うん、うん、わかる。
デザインパターン、うん、わかる、わかる。理解はできるぞ。

え、お前ら、いつ、どうやって使うん?
っていうかどうやって、そのパターン当てはめるんや?

たとえば、ファクトリメソッド・パターンってあるじゃないですか。
単純にwikiには生成に関するパターンだって書いてあるじゃないですか。
ああ、なるほど、生成が複雑になってきたらファクトリメソッド・パターン使えばいいのね。

HogeClass.new でええやん。
高尚な言い方すんなや。

そんなこんなで、オブジェクト指向の本など読み込み、
単一責任原則などを守るようにクラス設計するようになったものの
オブジェクト指向むずいと思いながら、
どうやってパターンを当てはめていくのかという 悩みを抱えながらしばらく生きていくことになりました。

しかし、結局この悩みがDDDに近づいていることになるのは、
聡い人はそろそろ気づいているかもしれないですね。

DDDと再び出会う

そんなこんなで私はオブジェクト指向に対する悩みを抱えながら、
いろいろ設計の本をそれからも読み漁っていました。

このころに設計レビューの話とか、
設計にまつわる合意形成、
そもそもの要求をモデル化する方法とかいろいろ模索していた時期です。

開発手法としては、特に気に入ったのがユースケース駆動開発実践ガイド で紹介されている
ICONIXというというソフトウェア開発手法でした。

この手法ではデータの保存場所と振る舞いを分けて分析することができ、
UMLとあわせて、クラス図やシーケンス図などを作成していく手法で、
これを使えば、おれも設計マスターだと思ったものです。

ただ、これでもぴんと来ないところもあって、
結局、『もし、モデルをこのように定義すると、、、』といった仮定を
たくさん置いて 確かめていく方法だった(結局、まぁ、いまもそうなんですが)ので
もうちょっとうまい方法はないもんかと、探していました。


そうやって、いろいろ探していたところ、 そういえば、俺、昔、DDDの本を買ったなと思って、 引っ張り出してきて読み始めたり、DDD関連のイベントに行ってみたりしてみました。

すると、DDDは『現実をある側面から抽象化し、それを実装に落とし込む手法』だと分かりました。

ほうほう。 概念を抽出するとな。メモメモ。
実装を実際にやってみて、それがそのソフトウェアとして使えるモデルとなっているか確認するとな。メモメモ。
声に出してみるとモデルが使えるモデルになっているかがわかるとな。メモメモ。

少し読んだだけで、モデル化するためにどんなことをすればよいのか
モデル化したものをどうやってパターンに当てはめていけばいいのかという指針が DDDには示されていることがわかりました。

ワイが求めていたものはこれや!

そこからはもう、迷うことなくDDDの勉強を開始しました。
最初は社内で『実践ドメイン駆動設計』の読書会を行い、大体毎週私が要約したものを話すというタイプの読書会を 敢行することことにしました。
とりあえず、『実践ドメイン駆動設計』は読み終えました。
非常に面白かったです。

現在、DDDとともに

2年前に『エリック・エヴァンスのドメイン駆動設計』の本を買った日に
ちゃんと全部読んでいたら、この本のすばらしさに気付いたのかもしれません。

ただ、人生そんなにうまくもいきません。
人生そんなもんです。

今も、『エリック・エヴァンスのドメイン駆動設計』の一人読書会を行っています。
実践ドメイン駆動設計』には書かれていない、より原則的な指針の部分が多く書かれており、
読み進めるごとに発見があり、非常に勉強になっています。

みなさんもよかったらDDD勉強してみてください。
もしかしたら、悩みが解消されるかもしれません。

ドメイン駆動設計 #1 Advent Calendar 2018 の明日は posaunehm さんによる
Entityについて話です。
また、DDDについての知見が深まりそうで期待が高まります。
お楽しみに。

コメント

このブログの人気の投稿

コーチやメンターとの付き合い方

ロバストネス分析をやってみるとモードレスっていうのはAPIも単純になっていいなと思った