What is it, naokirin?

Eric EvansのDDDを読んでます(3)

今回は第5章まで。

忙しかったのと、他の本を参照したりしていたので読むペースが少し遅くなってしまっていますが、またペースを戻しつつ進めたいと思います。

あと、ブログのデザインを変えてみました。 もともと大画面で見ている時に幅が狭いかなーと思っていたので、大画面では少し記事の幅が大きくなるように調整しました。

読みやすくなったかな…?

ソフトウェアで表現されたモデル

関連

ドメインを理解することで、関連の方向性と限定された関連を導く。
限定された関連は多重度を減らし、より多くの知識を伝えることができるようになる。

OOPでやっている時に、依存の方向性や関連が複雑にならないように限定するのと似たようなものでしょうか?

このあたり、仕様から実装へ移るときに明示的には意識できていないんじゃないかなと読んでいて思いました。

エンティティ

エンティティは同値性よりも、同一性(identity) によって定義されるオブジェクトである。

こういうときに、"identity"って便利な単語だなと思います。まさに"identity"。

例えば、勤怠管理システムにおけるユーザとかはそれかなと。 同姓同名だったとしても、別の人物であれば別のオブジェクトとして区別されるべきだったりするので。

またエンティティは同一性を保証するための機能が無いといけないため、その保証ができるための操作の設計が必要になる。例えば一意に生成されることが保証されるIDなど。 この同一性の保証に関しては、熟考したほうが良いことが本で示されていました。 例えば、病院をまたいだ医療記録などで、同一性をどう保証するかなど。

奥が深いですね。

値オブジェクト

概念的な同一性がなく、物事の特徴を記述するオブジェクトである。

色とかはそうですかね。

Yellow と 黄色 のどちらを選んでも本質的には変わらないので実際には 「Yellow = 黄色」の図式が成り立つ、みたいな感じですかね。何であるかが重要な問題であって、誰とか、どれとかは意識しなくてよい場合に現れるのが値オブジェクトである、と。

本を読むまでは不変であることが当たり前のようにイメージしていましたが、可変であっても問題ないようですね。 とはいえ、出来る限り不変に設計するほうがよいようですが。。。

サービス

概念的にどのオブジェクトにも属さないような操作を、ドメインに沿った自然な形で表現する。

サービスって、どれをサービスにするかって難しいところじゃないかなーと。 多分、各オブジェクト間でのやりとりで、それを各オブジェクトに持たせるとややこしくなるタイプの操作って感じだとは思うのですが、まだモヤモヤしたところが取り切れていない感じです。

モジュール

モデルにおいて意味のある一部として現れ、より大きな尺度でドメインを表現する。

モジュールを読む際にはマイヤーのOO入門を引っ張り出してきて、少しモジュール性のところを読んだりしていました。 モジュールは低結合・高凝縮であり、内部をよく表現したものである必要があるというのがやはり必要ってことかなという感じでした。ただ、ここにドメインをしっかりと反映するのは大変かなと。

あと、リファクタリングされないモジュールは上記のような低結合・高凝縮で内部をよく表現し、ドメインを反映したものにはできないため、必要ならば再構築などもしっかり行っていくべきだと書かれていました。

モデリングパラダイム

モデル駆動設計では、モデルに対応した実装技術がなければならないということが書かれています。とくにあるとしても成熟していなければ、それを行うことに対してリスクがあるということも書かれています。

最後にパラダイムを混ぜることについても書かれていますが、つかみにくい場所もあったので、次の章を読みつつ更に理解を深められればよいかなと思っています。

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)