読者です 読者をやめる 読者になる 読者になる

気の向くままに書き綴る

勉強会参加したメモや日々の思ったことのメモ等

【Devlove2012参加】ドメイン駆動設計という仕事の流儀

ドメイン駆動設計という仕事の流儀
増田 氏
http://www.slideshare.net/masuda220/ss-15655472

ドメイン駆動設計の腕を磨くと
 ・仕事が楽しくなる
 ・喜んでもらえる
 ・自分の成長の手応え
 ・やっていて楽しい

 ドメイン駆動設計
  利用者のやりたいことに対して、興味を持つ。いつも話題にする。モデルに要約する。コードで実現する。
  テクニカルな部分でも、サービスをどれだけ意識して喋れるか

 アーキテクチャ

 ドメインモデル思考の設計パターン
  ドメインイベントーーモデルに近い?
  起動 ドメインサービスーー受付クラス(){}
  委譲 ドメインモデルーー会員とは?入会とは?申し込みとは?受付とは?
  
 ドメイン層の基本部品
   入会申し込み
     →会員登録サービス→会員リポジトリ(DBアクセス)
              →会員トランスファー(メール送信)
              →会員  
 アンチパターン
   大きなサービスクラス
    5以上のimport文
    5以上のインスタンス変数
    10行位上の長いメソッド
    50行を超えるクラス
 ドメインモデル思考のフレームワーク
    ドメインモデル
     フレームワークからif文を書かなくなっている
 ドメインを把握して、固めてしまう    

 開発プロセス
  1.コンテキスト
  2.業務フロー
  3.ユースケースAndイベント
   →画面・帳票 状態遷移 ロバストネス分析
  1.初期のラフモデル
2.モデルの改良
3.モデルの洗練
4.属性の通知・データ・モデル
5.操作追加
6.基盤クラス追加
  →コンテキストがきたら、二時間以内までに初期のラフモデルを作成してどんどんモデルの改良を行う

  【Evolving】小さくフィードバックを反映しながら育てる
  【Pervading】多くの関係者、あらゆるタスク、ドメイン以外のレイヤ
  【Binding】コードと資料を結びつける
  →イテレーティブで発見的によりよい部品を探し続ける
  →モデリング・リファクタリング・プログラミングすべてを意識して行う
  

 設計スタイル 
  ぎゅっと集めて
    パッケージ・クラス・メソッド
  サラッと繋ぐ
    業務の概念ごとに独立させてサラッと繋ぐ
     (同じ部門で同じような業務があった場合、共通のクラスにしては行けない!
      なぜか?部門ごとに業務の変更が入る可能性がある)
    パッケージ・クラス 
  メインオブジェクトに適用する

 ドメインクド樹設計のへの道
   1 アンソロジー
   2.1  リファクタリング RubyEdition
   2.2  実装パターン
   3.1  オブジェクトデザイン
   3.2  実践UML
   3.3  アジャイルソフトウェア開発の
   3.4  エリック・エヴァンスドメイン駆動設計

  要求定義マニュアル  
  ユースケース駆動開発実装ガイド
  ITエンジニアのためのビジネスアナリシス

  ドメインオブジェクトの理想形
      NextStage(){
       ready();
       setup();
       go();
      }   
      HowよりWhatを意識して作る

    学びパターンT型で
       まずは、プールを作り
       鳥の目と、虫の目で掘り下げて学ぶ
       そしてプロトタイプを作る
    →抽象化されたものから、現場に生きることはない
    →現場から、抽象化されたものが次へいきる

原則やパターンは北極星と同じである。北極星を目指すのではなくて、北かどうかを知りたいだけだ。

【参考リンク】
http://www.slideshare.net/masuda220/ss-14263541
http://www.slideshare.net/yojik/ss-1033616
http://www.slideshare.net/MoriharuOhzu/ss-14083300