-
Notifications
You must be signed in to change notification settings - Fork 5
vol9_20140713
- 日時：2014/07/13 14:00 - 17:00
- 場所：市民交流センターなにわ 104号室
- 範囲：第5章の[p103.サービス]から、第5章終わりまで、15章「汎用サブドメイン」「凝集されたメカニズム」「隔離されたコア」
- 方法：数分間黙読後、グループでディスカッション
- レポート担当 spring_kuma( @spring_kuma )
サービスという用語が一般的すぎて話が混乱しやすいかもという印象をうけた
- 他のレイヤーにもサービスという役割がある。ここでいうサービスはドメインレイヤーでのサービス
- インフラにあるものと混同することは多いが、ちゃんと区別して考えましょう
サービスというのは類型化すると以下のようなものにまとめられるのではないか
- (1)「ユースケース」として表現出来るもの
- (2) 過渡的なものとして「分類不能」としてまとめられるもの
ユースケースとしておいておくための自然な場所として用意するという使われ方はわりとよく利用されている
- 例えば、動詞とか活動の名前がつく
オブジェクト指向のメンタルモデルについて
- James O. Coplien（@jcoplien）は、著書で認知言語学の創設者の一人であるジョージ・レイコフ（George P. Lakoff）の概念メタファーを取り上げ、人間のカテゴリ化のプロセスは古典的モデルに基づくのではなくメタファーによるというレイコフの理論を紹介している。（マルチパラダイムデザイン p.29） (個人的に面白い捉え方と思いました。メンタルモデルというのはMVCを提唱したReenskaug博士の論文にも出てくる 概念ですが、直接的な写象というよりはいったんバッファをおいた概念、メタファーとしてとらえたほうがしっくりいく と思います)
ここにあるのが自然だとして、考え始めると難しくて行き詰まってくることはあるかもしれない (オブジェクト指向的な自然と、モデリング的な自然のギャップもあると思います)
ユースケースというのは、イベントと同義か？(質問)
- あるエンティティと別のエンティティをイベントが紐付けている、その全体がユースケースというイメージ
サービスのライフサイクルがわからない いつnewするものなの？ Singleton的な感じで実装するのかな？
- DDDの関心事ではないと思われる。実装として、DIのコンテナの設定とかシングルトンとか色々考えられるがDDD本としてはそこは考慮の対象にはしていない。あくまで、DDDはモデリングの考え方を対象にしている
実装の問題として捉えると、サービスが複雑化する可能性がある
- 実装だけで考えると、CQRS、イベントオブジェクトをかぶせるなど複数のアプローチはある
サービスは、ドメイン層だけのものだけではない、インフラ層、アプリ層にもある
モデリング対象として、
- エンティティ、値オブジェクト、サービスという設計上の要素を明確に区別しましょうというのがこの章の主眼。
- 実装が終わるまでは、デザインと実装と適したところはわからないので、行ったり来たりするもの
- 概念的に表現することと、実装することは別で行き来しながら洗練されていく
- この3つのモデル要素は型として機能する(設計のテンプレートとして)
複雑性を隠ぺいするのがサービス
- 呼び出すときは、純然たる動詞と、引数
- 複雑性を隠蔽するためのもの
DDD本全体にわたって、モデリング技法というのはあまり紹介されていないが、この章は珍しい例で技法について紹介している
- 他には責務のレイヤの章くらい
- T字モデリングなどは、モデリング技術を説明したもので、DDDと矛盾するものではない
概念モデリングのツールで現在の開発環境で何を使われてますか？
- なにを使わないといけないというのはない
- 近年は、昔と違って、UMLでも、少し崩したUMLで良い（標準準拠に拘らなくても良い）と思っている
- ERDそのものは「概念モデル」ではない
- 「枠」と「線」さえあればけっこう何でも表現できるのでは
- 渡辺幸三さんの三要素分析法、業務フロー図
- マインドマップも良いですね
登場人物として、エンティティと値オブジェクト、サービスどういう役割があるんでしょうか？とくにサービスの役割について
- 複数のインスタンスが登場するようなもの、コラボレーション的に提供するものがサービスと捉えてよいのではないでしょうか？
- ロジックを散らばせないことが重要
(例を出して)、エンティティ(商品)、値オブジェクト(価格)、その中でユースケース的なものの収まりどころというのはある
- ユースケースとしておさまるものではないところに、もしかしたら価値があるのかもしれない。検討すれば新しい概念、モデル要素が生まれる可能性がある
- 「分類不能」なサービス（冒頭で挙げたサービス類型の(2)）の重要度は、「ユースケース」的なサービス以上に着目すべきである可能性がある。着目すべき
DDDを実現するためのツール/設計手法として、オブジェクト指向である必要はない
- 実現するためのツールはいくらでもある。
- 概念としては古くならないので適切なものを使っていければよいのではないか
- モデリングとしての考え方は決して古くならない
サービスには状態がない
- 基本的にはそう。でも、そうでないものも出てくるかもしれない
- でも、状態を持ってしまった場合は、エンティティにすべきものを持ってしまっている可能性があるので、それがエンティティではないのかという検討はすべき
DDD本においての「ドメイン」の定義
- この本ではあまり厳密に定義されてはいない
- 例えば、「マルチパラダイムデザイン」においては、分析してドメインとして認識した結果の領域という定義がある
DDD本全体として業務アプリの例が多いのは、対象業務が複雑だからでは？
(モジュールの)実装速度とかそういうのがドメインとなりうるかという議論があったが、そこはなりえないんじゃないかという結論
- コンパイラとか解決領域の問題
- なにが問題か(what)、どう解決すべきか(how)という問題構造があってそれが多層になっているという話
- 下層の機構にも、方針と機構がある。フラクタルな構造を形成する
- 方針と機構を分離することは重要
- デイビッド・パーナス（David Parnas）の情報隠蔽（Information Hiding）
- 方針の部分が絶対的に重要 ユーザは方針しか見ないです
横断的な関心事をまとめて処理する構造
- 垂直ドメイン(アプリケーション層)と水平ドメイン(横断的な関心事)これらはAOPがでて扱いやすくなった
共通性と可変性
- ビジネスドメインのメカニズムは安定しているがポリシーは経営と競争に関連しているので進歩変化しやすい
- そのなかで、メカニズムは隠蔽しておこうというのは自然な発想
- メカニズムは共通性、ポリシーは可変性
- バインディングタイム、束縛のタイミング
- 可変性がどのタイミングで決まるのかを決定することはとても重要
- BEAR.Sundayはそのへんを強制してくるのでとてもよい
- 設計がそのへんのバインディングタイムとかを考えていかないといけない
フレームワークあるいはDSLは制約を課すもの
- 制約を課すことで、逆にアプリケーションの設計に注力することができる
DDD本が書かれた当時は2003年。そこからは色々フレームワークが手助けしてくれる世界になっている。解決レイヤーをサポートしてくれるものが多いが、次はドメインレイヤーを手助けしてくれるものが次の狩場になっていくのかもしれない。
方針と機構の分離の側面として、機構としての凝集されたメカニズムと汎用サブドメインを紹介
既知の汎用的な知見を活かす部分
例えばコアドメインを宣言的な手法に変換することもできる
関連する章としては
- 意図の明白なインタフェース
- 汎用サブドメイン
- 隔離されたコア
- 仕様
あくまで、方針と機構
- 方針を表現するノイズみたいなものを機構に押しこむ
- 集中するのは方針のみ
- AOPとかを上手く活用する
このあたりは、10章とかを読み返してから、読んでもいいかもしれないですね
積極的にDDDを支援するようなFWは存在しない
- より直接的に関心事を取り込むようなものが、これからFWにとりこまれていくのではないか？
- これまで、垂直的な関心事(アプリケーション)と考えられていたものが、水平化されていく。このへんはやりやすいものから
シングルサインオンみたいな統合は便利だが、その中で統合されたダッシュボードみたいなものはない。これから情報の集約的なサービスとかも出てくるだろう
開発業務はなかなかIT化しづらい領域なのかも
8/3 新大阪 東口 「市民交流センターひがしよどかわ」
7/28 関西IT勉強宴会
- 18:30〜
- 渡部幸三さんによる「受注生産」のためのシステム開発ライブ
- 三要素分析法とXEAD Driverの作者の方によるライブモデリングです
- 設計者の発言