※この記事は書きかけの記事です。
第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
ドメイン駆動設計
なぜDDDか
現状ではDDDを利用した設計をしたことがないのでうまいことメリットを説明できないので、動画を貼っておきます。
https://youtu.be/77BTZWq3GiQ
https://youtu.be/FNEfk-dlIKU
DDD参考資料（ネット）
http://d.hatena.ne.jp/asakichy/searchdiary?word=*[DDD]
http://d.hatena.ne.jp/j5ik2o/searchdiary?word=*[DDD]
http://d.hatena.ne.jp/higayasuo/20080519/1211183826
http://qiita.com/opengl-8080/items/4f8938c65d8a2b7e50d0
http://labs.gree.jp/blog/2013/12/9354/
DDD参考資料（本）
エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)
実践ドメイン駆動設計 (Object Oriented SELECTION)
ドメインイベント
DDDにおいてはドメインが最大の関心事
サービスは消極的に作成する
基本的にはエンティティと値オブジェクトを使用するように設計します。
サービスに頼ってしまうと
サービス毎に分断されてしまうため同じ処理が各サービスに散らばる危険性がある。
またドメインモデル貧血症に陥ります。
http://bliki-ja.github.io/AnemicDomainModel/
エンティティとは何なのか
振る舞いを持つ。
Serviceをextendsすることもある。
DIをどうするか
scalaを使用すると以下のようなシンプルなDIを実現することが可能です。
シンプルなDI
http://www.michaelpollmeier.com/2014/06/29/simple-dependency-injection-scala/
ただし、このシンプルなDIがDDDで活用できるかどうかはちょっとまだわかっていません。