先日、エリックエヴァンスの読書会を開催した際に、
第３章のモデル駆動について様々な意見が出たので、そのことについて記事を書きたいと思います。
実は上記の読書会以外にも、
自分が主催でやっているICONIX手法でやってるモデリング勉強会(SOLIDなどの原則も含む)があるんですが、
エヴァンス書籍で書かれてる内容はよくよく考えてみたら、結構無意識にやっている内容でした。
だからドメインモデルと実装が解離しないようにしようって発想は
「え、、そんなん当然に思うことじゃない？？」ってなってましたが、
実際の業務では、ドメイン分析を行う方、設計を行う方、実装を行う方が分断されてしまってるんだとか。
あとは仕様変更が入った際に実装だけを修正して、
それがドメインモデルが変わらない、影響しないようなものであればいいんだけども、
ドメインモデルの構図が変わるような仕様変更だった場合、実装と解離してしまい、
結果的にそれが何度も続くと、何のためにオブジェクト指向で作ったの？ていうくらい
保守性の欠如したものになってしまうんだとか。
それに対する対処法は書籍には特に具体的には書かれてなかったから、
そこに対する心構えとか、対策法、そもそも設計とドメインモデルの違いって？みたいなディベートをやってました。
※以下は書籍を通して皆で出し合ったものと、個人的見解が含まれますので、絶対的な正解ではありません。
※またドメインモデルって言いにくいから、独断と偏見で【分析クラス図】と書いてしまいます。
分析段階でのクラス図って意味でね(^_-)-☆
まずは結論の項目から。
【アジャイルはドキュメントよりも動くもの重視って文献を誤解している】
【１回目のモデルで完璧を目指そうとしてはいけない。かといってテキトーな名前もNG】
【そもそもモデラーと開発者を分けてはいけない。全員でなるべくモデリング、全員で開発まで担当。】
確かにアジャイルではドキュメントは最小限に、動くものを最優先て提唱されてますが、
だからと言って分析クラス図などのドキュメントをおろそかにしろ、とは言ってないです。
新しい仕様変更が分析モデルの構図を変えないといけないような場合には、
今あるモデルに追加して対処しようってよりは、崩れるのが当たり前( ･´ｰ･｀) くらいの心構えで
迅速にモデリングをすべきだなあと。
（もちろん構成がほとんど変わることなく追加で対応できるものもあるとは思いますけど）
現に実体験として自分たちのモデリング勉強会で
「図書館の貸出返却システム考えよう！！
ますは貸し出しの際の貸し出し担当をやってくれる図書館スタッフである【司書さん】はシステム化の管理対象だけども、
返却する際には、複数の蔵書をバラバラに返すことおあるから、
その返却の際の司書さんが誰なのかまでは面倒だから管理対象から外したモデルを考えよう！」
て作ったモデルと、
「今度は返却の際に、返却担当する司書さんが誰なのかまで管理対象にしてみよう！！」て作ったモデルは
劇的にドメインモデル図の構成が変わりました。
だいぶ端折りますが、前者では返却明細と貸出明細は一緒のクラスにまとめてしまってOKだったけども、
後者では返却明細を分けてあげないと表現できませんでした。
最初はまとめてしまってたクラスでも、仕様が変わると分けないと単一責務違反になってしまうケースなんて
他のモデルでもざらにありました。
こんな感じで仕様変更が入る度、素早いタイミングで作ったものを壊しては作って
を繰り返して、さらにはその都度非機能部分まで変わる可能性あるから設計モデルまでも猛烈なスピードで
変化を求められてしまう。
これはめっちゃ心理的にしんどいなあ汗と感じました。
だからエヴァンス本で言ってることは、私個人としては
「壊すことを恐れるな。捨てることを恐れるな」て思えました。
何度も何度も破壊しては創造を求められるわけだから、
確かにモデルを中心に議論して実装に落とし込むってのはあるけども、
最初から完璧な名前などを目指さなくていい。
意思疎通が図れればいい。
モデルを作ることを目的としてはいけない。
モデルを作るのはあくまでも【顧客や開発者含むチーム全体の意思疎通のため】。
つまりまとめると、
最初からモデルを創りこみすぎない。かといってテキトーなわかりにくい命名はやめる。
そして、神クラスが発生しないように責務を単一になるようにしておく。
分析モデルの段階で求められるのは、カプセル化高凝集。
そして何より大切なのは開発者だけでなくチーム全体で対話をすること。
そしてWhyが伝わらないってことが起きないように
チーム全体で実装まで行うこと。
これがモデル駆動設計の章で言いたかったことなんじゃないかなと思いました。
てなわけで～～
理屈ではわかっていても、体験を伴わないとダメな気がするんで、今度モデリングの祭りをやってきます！！
おわり