More than 5 years have passed since last update.

責務配置設計 - DDD第1歩

Posted at 2015-12-27

※この記事は書きかけの記事です。

第1歩なのでサラッと行きます。

ツッコミ待ってます。（ただし、鉞は怖いのでやめてください）

責務配置とは

せき‐む【責務】
責任と義務。また、果たさなければならない務め。「―を負う」
https://kotobank.jp/word/%E8%B2%AC%E5%8B%99-547440

Controllerであれば View と Model をつなぐのが責務であり、ビジネスロジックは責務の範囲外といった感じの、それぞれが担うべき役割。

責務配置について考える必要性は、責務配置がなかったらどうなるのかという視点から見ていきます。

何か処理を追加したい、変更したいと思った時にどこに処理を追加すればよいのか、変更したい処理がどこにあるのかを発見することが困難になり、生産性が落ちます。
生産性が落ちるだけならまだしも、同じ処理が各クラスに記載されて保守性が落ちる可能性を大いに孕んでいます。

また、いわゆる技術的負債をどんどん積んでいくことになるわけです。
あなたの技術的負債を返済するのは誰ですか？あなたですか？見知らぬ誰かですか？
他の人の技術的負債を返済するのは誰ですか？

責務配置を考える上ではきちんとした設計思想が必要となります。

DDD,DCIとかあるみたいですが、全然詳しくないのでほかにどのような思想があるのか情報提供を受けたいです。

ちなみにNTTデータさんのTERASOLUNAのアーキテクチャを見るとひとつこういった思想もあるのだというのがわかります。(But Not DDD)
http://terasolunaorg.github.io/guideline/5.0.0.RELEASE/ja/

先日ソースコードのお掃除の記事を書きましたが、既存コードをDDDの設計に切り替えるのは無理だと判断しTERASOLUNAと同じ思想でリファクタリングを行いました。
http://qiita.com/FScoward/items/539e62098088e09cb757

ドメイン駆動設計

現状ではDDDを利用した設計をしたことがないのでうまいことメリットを説明できないので、動画を貼っておきます。
https://youtu.be/77BTZWq3GiQ
https://youtu.be/FNEfk-dlIKU

DDDにおいてはドメインが最大の関心事

基本的にはエンティティと値オブジェクトを使用するように設計します。

サービス毎に分断されてしまうため同じ処理が各サービスに散らばる危険性がある。
またドメインモデル貧血症に陥ります。
http://bliki-ja.github.io/AnemicDomainModel/

振る舞いを持つ。
Serviceをextendsすることもある。

scalaを使用すると以下のようなシンプルなDIを実現することが可能です。

シンプルなDI
http://www.michaelpollmeier.com/2014/06/29/simple-dependency-injection-scala/

ただし、このシンプルなDIがDDDで活用できるかどうかはちょっとまだわかっていません。