東北デベロッパーズコミュニティ(TDC) 東北デベロッパーズコミュニティ(TDC)


L O G I N
ユーザー名:
パスワード:



DDD勉強会 : 第5回DDD勉強会



masanori.murakami


Re: 第5回DDD勉強会
投稿日時: 2012/1/20 20:44
3.関連の設計

 双方向の関連はなぜだめか?
 理解しにくいモデリング
 関連がたどれる方向 = 理解しやすいモデリング

 関連の設計理由

 配送仕様と位置の関係が、なんで双方向なのか?
 書き忘れているだけ?
  >和智さん質問項目!!!

4.集約の境界

 ライフサイクルが同じオブジェクトはどれか??
 ルートエンティティを見つけるポイント
 ・グローバルな同一性をもつ
 ・教会のオブジェクトを保持する

 ルートエンティティの候補

 設計判断の理解

 アプリの要件的な理由も考慮されているかもしれない。

5.リポジトリの検討

 4つのリポジトリ候補
  顧客、位置、輸送機器、貨物

 調べる要求が無いもの
  荷役イベント

6.シナリオのウォークスルー

 目的 アプリケーションの問題を公家庭に解決できるか確認する。

 

masanori.murakami


Re: 第5回DDD勉強会
投稿日時: 2012/1/20 20:16
第7章
 例題
  荷役を追跡できること
  貨物を予約できること

 概念を表した図
  原文の解釈
  
 オブジェクトの定義の確認
  配送
   みなさんの認識・・・
 
 パターン適用の流れ
  1?7

  1.ドメインの適用
     3つのアプリケーション層
     アプリケーションクラス=コーディネーター
  2.エンティティと値オブジェクトを区別する
     どれがエンティティで、値オブジェクトか?
     値オブジェクトでも良いんじゃないか?
     値オブジェクトでだめな一例は、同じ名前ではだめな場合
     ↑それがエンティティ
     時間が経過しても変わらない物がエンティティとして捉えた。
     営業所AからBに移した場合は、追跡できないとまずいかな?
     オブジェクトの属性が普遍であるものは、値オブジェクトの特性
     
     なぜ配送仕様だけ値オブジェクトなのか?
     値オブジェクトは、情報の共有ができる。
     貨物に対しては、共有できる情報なので、値オブジェクトになる。

masanori.murakami


Re: 第5回DDD勉強会
投稿日時: 2012/1/20 19:49
第7章

 目的 これまで学んだパターンの適用例
    設計の問題と解決策

 9つのパターンのおさらい
    レイヤー化アーキティクチャ レイヤ分割
    関連
    エンティティ 本質が変わらない物
       顧客IDのような変更が無いもの
    値オブジェクト なのを表したものなのか?
       属性値が同じだったら、インスタンスが別でも同じ P97のコラム辺り
    サービス ドメインの中で需要なプロセスや変換処理をまとめたインターフェイス
       ただし、エンティティや値オブジェクトの責務から外れるもの
       インフラ層は、イメージしやすい。
       ドメインレベルのサービスは、イメージしにくい。
       複数のモデルが関与するサービス
       同じクラスでも別インスタンスでやり取りをするもの。
       2つの銀行口座を操作するもの。
       口座の送金とか
       とらえ方が難し。
    モジュール(パッケージ) システムの概念を伝えやすく分割したもの
       システムに影響されるにモジュールの詳細を伝える。
    集約 関連するオブジェクトの集まり データを変更する単位
       ライフサイクルが同じクラスの集まり
    ファクトリ 複雑なオブジェクトの生成を簡略化して使わせる方法
    リポジトリ 特定のオブジェクトへの操作の詳細を隠蔽して扱いやすくする。
       CRUDのCは入らない。Cはファクトリの役目。
    おまけ 利口なUI すべてのビジネスロジックを含んだUI

 

masanori.murakami


Re: 第5回DDD勉強会
投稿日時: 2012/1/20 19:33
復習のディスカッション

 ・コードに落としてみないと、実感がわかない。
 ・今後の勉強会で、コードを書いてみたい。
 ・リポジトリ P154
   Q.トランザクション制御をクライアントゆだねるというのは、一般的なのか?
   A.JDBCをべたで使ったりすると、リポジトリの外に出してしまう。
     JTAを使って、サービスに持ってくると、アプリケーションのサービスが一つのトランザクションになることが、一つの理想。
     リポジトリの操作は、シンプルなはず。
     使われ方によって、操作を用意する。

     

masanori.murakami


Re: 第5回DDD勉強会
投稿日時: 2012/1/20 19:26
復習の続き

 P159 関係データベースに合わせてオブジェクト設計する。
 1.データベースとのマッチングを簡素化するために、モデルに制約を設ける。
    シンプルであることが重要。

 2.データベースが、別なシステムのために設計されている場合
    レガシーや、外部のシステムから来ている場合
    モデリングの理想を崩した・・奇抜な変更
    ユビキタス言語で、オブジェクトモデルと関係モデルのコンポーネントを結びつける。
 3.データベースは、オブジェクトを格納する以外の役割を果たしている。
    ドメインモデルと関係ないスキーマが格納されている。
    ドメインモデルと、データベース上のデータに乖離が発生することがある。
    意図的にドメインモデルとデータベーススキーマを分ける場合は、間に層を設けるとかしたほうが良いかもしれない。


 
 

masanori.murakami


第5回DDD勉強会
投稿日時: 2012/1/20 19:14
1.前回の復習
  ・リポジトリの構造。
  ・リポジトリに対して問い合わせる。
  ・クライアントのコードは、リポジトリの実装を無視するが、開発者はそうではない。
  ・フレームワークの範囲内で作業する。
  ・ファクトリとの関係
    ファクトリ オブジェクトのライフサイクルの始まり
    リポジトリ 中期から、終わりまでを管理