スポンサーサイト

  • 2016.05.30 Monday

一定期間更新がないため広告を表示しています

  • 0
    • -
    • -
    • -

    第4回 IDDD読書会 に参加してきました

    • 2016.05.17 Tuesday
    • 03:45
    第4回 IDDD読書会(https://iddd.doorkeeper.jp/events/43687)に参加してまいりました。

    この読書会はファシリテーターの方が最初に要約をまとめて説明して頂いて、そのあとディスカッションするスタイル。
    要約が非常に判り易く勉強になります。
     

    今回の範囲は4.4サービス指向から4章末まで。
    4章はアーキテクチャ全般の話となります。
    注意点として、境界づけられたコンテキストの大きさがアーキテクチャによって影響を受けないようにすること。 
    4章前半で話されているCEOへのインタビューにおいて、DB変更やスケールアウトなどがスムーズに行えたという話が出ていますが、それはアーキテクチャがドメインへの制限にならなかった左例でしょうか。

     


    ■RESTとDDD 

    主な手法は2種 

    ・システムのインターフェースレイヤを境界づけられたコンテキストとして分離して、適切な戦略を用いてインターフェースのモデルから実際のコアドメインにアクセスする方法。 

    ⇒つまりユーザのタスク情報を取得するのに/user/task としたときに、ドメインオブジェクト直接取得するのではなく、何らかのインターフェース用オブジェクトを返すようにしておけば、taskドメインオブジェクトが変更したとしても、このRESTを使用している各アプリは直接変更影響を受ける度合を軽減することができる。 


    ・標準メディアタイプの利用 

    ⇒ドメインコンテキストをまたがって利用できるオブジェクトを返す。 
    ⇒DDD的には「共有カーネル」「公表された言語」など 。
    ⇒具体例としてはiCalフォーマット呼ばれるスケジュール標準フォーマット。これは公表された言語であり多数のアプリに実装されている。ドメインオブジェクト自体をicalフォーマットに合わせて作成を行う。 

     

    ■RESTを選ぶ理由 

    RESTの原則を満たす設計システムは、疎結合であるという要件も満たしているから。 

     


    ■CQRS(コマンドクエリ責務分離) 

    メイヤーが提案したCQS(Command Query Separation)が元になったアーキテクチャパターン。
    何らかの処理を実行するCommandと、問い合わせを行うQueryを分けようとうのが原則。 
    そうしないと、裏で何が処理されているのか判らなくなってしまうため、安心してQueryする事ができなくなってしまう。 

    DDD的にCQRSを使用するのメリットとしては、効率性・拡張性などの実装都合によります。 
    ドメイン駆動で、複数の集約データや、集約データをまたがるときなど単に愚直にリポジトリパターンでデータ取得するときなど、実装効率が良くない場合、効率よくデータ取得するために専用のQueryを用意するなど行います。 
    つまりドメイン駆動だから、モデル層がという話ではなく、スケーラビリティ的理由により活用されています。
    また、Queryモデルは、非正規化したデータモデルであり、ドメインのデータというよりは表示用(もしくは印刷)用のデータと見なす。 

    CQRSを学ぶ際、下記ページを参考にさせて頂きました。 
     

    Greg Young流CQRS - Mark Nijhof 
    http://d.hatena.ne.jp/digitalsoul/20100712/1278886009


    CQRS Journey 
    https://msdn.microsoft.com/ja-jp/library/jj554200.aspx?f=255&MSPPError=-2147217396


    DDDで設計するならCQRSの利用を検討すべき 
    http://qiita.com/ledmonster/items/22b00c65208dffeff7e4 


    [CQRS Documents by Greg Young]の和訳 
    http://www.minato.tv/cqrs/cqrs_documents_jp.pdf 


     

    ■パイプとフィルター 

    パイプとフィルターの特性幾つか挙げられてますが、個人的には疎結合と視認性の良さにあると思います。 


     

    ■イベントソーシング 

    CQRSと同時に使われるのが多いのがA+ES(Aggregates and Event Sourcing) 
    ドメインモデルとして、多くは非同期つまり結果整合性で済むことは多いと思います。 
    しかし、難しくなるのがUI設計。 
    非同期で発生したエラー通知などは、どうすればいいのか今でも試行錯誤です。 

     

    ぐるぐるDDD・Scrumに参加してきました!

    • 2014.03.23 Sunday
    • 13:46
    2014/03/15にDevLove関西で開催された『ぐるぐるDDD/Scrum - ドメイン駆動設計。モデリングと実装のうずまきをまわしてみよう』に参加してきました。
    http://devlove-kansai.doorkeeper.jp/events/8246

    DDD本(鈍器)を読んで、悶々としていたところに、DDDのワークショップを開催するということで、これ幸いとスタッフとして働くことを条件に参加してまいりました。


    今回は、講師をして頂きました原田様、会場提供頂きましたエムオーテックスの井上様には多大なるご尽力頂きまして、誠に有難うございました。
    改めて御礼申し上げさせて頂きます。
     

    PR

    calendar

    S M T W T F S
        123
    45678910
    11121314151617
    18192021222324
    252627282930 
    << June 2017 >>

    selected entries

    categories

    archives

    recommend

    recommend

    recommend

    recommend

    profile

    search this site.

    others

    mobile

    qrcode

    powered

    無料ブログ作成サービス JUGEM