この記事は第2のドワンゴ Advent Calendar 2015の22日目のエントリです。
Goでgxui使って2画面ファイラー作ってワショーイしてたんですが、もうちょっと寝かしたいなと思ったので他の事書きます。
こっちはこっちで追って公開したいですね。
というわけで本題です。
はい。Evans本3部4部ちゃんと理解してない人はやり直しです / “ドメイン駆動設計の間違った方向性” http://t.co/tcgxlWVONq
— ソフトウェア設計おじさん (@uzzu) June 25, 2015
Evans本の1部3部4部ちゃんと理解してない人は2部読む権利ないですよ
— ソフトウェア設計おじさん (@uzzu) June 25, 2015
Evans本、2部から行くのがライトウェイトだって言ってる人まだいるのか。SBRじゃないけど、遠回りこそが最短ルートだったよ(私は)
— ソフトウェア設計おじさん (@uzzu) October 5, 2015
こんな事ばっか言ってる2015年でした。
DDD初見さんお断りするようで、こういうこと言うのも正直嫌なんですけど、
慌てる必要はないので、ゆっくり勉強しましょう。
2部から始めるのは本当に危険で、2部読むくらいなら責務駆動設計を学んだ方がマシです。
オブジェクトデザイン読みましょう。
DDDでおさえなければいけないのは実装パターンではなく、 以下にあげるような内容です。
あまり時間を作れなかったので、特によく考える3つだけ書いておきます。
本当にドメイン駆動設計を用いて「実装」すべきなのかを検討する事
ソフトウェアは1人で構築するものではありません。
(時にカウボーイとして1人になることもありますが、そうなった場合にどうすべきかは考えるまでもないですね:))
一機能を実装する間、コーディングは貴方1人で行っているのかもしれませんが、他の機能を実装しているDeveloperがいて、それぞれにPlannerの意志があって、時には外部のContributorがいて、と関係者はたくさんいます。
実装面は特に、メンバーのスキルセットやモチベーションを加味しなければなりません。
そんな中で、ゴリ押しでDDDを推進して良いのでしょうか?
実装として実践することは良いことですが、何もドメイン駆動で実装する事がドメイン駆動の本質ではないです。
普段の会話にすら、実践する場があります。
上司やお偉いさんの言ってる事がよくわかんないんだけど、つまりこういう文脈があって、この人は暗黙的にこういうドメインを構築していて、こういう単語や動詞を使ってるんだな
って洞察を行いながら会話をすることも、立派なドメイン駆動です。たったこれだけで、以下のパターンが絡んでいます(洞察するともっと絡んでるかもしれません)
- ユビキタス言語
- 実践的モデラー(とドメインエキスパート)
- コンテキスト境界
- 継続的な統合
- コンテキストマップ
- 共有カーネル
- 顧客/供給者の開発チーム
- 順応者
- 腐敗防止層
- 別々の道
- 公開ホストサービス
- 公開された言語
加えて、開発にはもちろん期日があります。
その際、Monolith-Firstから始めるものの、将来的なリファクタリング戦略に支障がでないよう
責務レイヤーをしっかり構築しておくというのも1つの手です。
YAGNI言いますけども、それぐらいの未来は構築してもいいと思います。その代わり責任とってよね。
ドメイン駆動設計でソフトウェアを構築するのであれば、ドメインとは何かを定義する事
ドメインを定義しなければ、異なる文脈を持った余計なシナリオが介入したりして、やがてそれらの違った文脈を整える神(God)が宿るでしょう。 ドメインビジョン声明文を書いていますか?
コンテキストを常に念頭に置き、ドメインに対する深い洞察力を身につけること
Repositoryパターンは永続化という側面から見ると一見責務は1つですが、より洞察を行うと、ReadとWriteの成分があるので、SRPに反しています。 DomainEventを中心としたアーキテクチャではRepositoryは分解されるべきなのではないか、と思うことがしばしばあります。
プログラミング言語仕様のnamespaceにも着目してみます。
ドメインが成熟し、文脈が構築されていく中で、これらの機能を用いた表現も検討すべきです。
よくDDDのサンプル実装ではDomainとかInfrastructureとかnamespaceを掘ってますが、本当に必要でしょうか?
もちろん、この構築方法にもサンプルを示すというコンテキストがあって、そうしているのだと思います。
「空間」であるはずが、空間をまたいで水平方向の空間に依存しているようにみえて、個人的にはちょっと先行きが不安になります。
仮に正しく空間として取り扱った場合、ドメインモデルが1ディレクトリに溢れて辛い事になります。C#ならnamespaceではなくディレクトリ掘り、それをモジュールの単位と定めるのが良いでしょう。
packageやmoduleでは、またアプローチが違ってきます。
このように、言語仕様や、設計パターンそのもの洞察し、より深いドメインモデルの構築を行う事もしばしばあります。
まとめ
ドメイン駆動設計理解してないからって死ぬわけじゃないから、焦らず勉強しよう。