タグ

ドメインに関するsugimoriのブックマーク (11)

  • リレーショナルモデルにおける制約とCQRS・SQLQL - こまぶろ

    前回の記事で、リレーショナルデータベースの役割として、以下の3つを挙げ、ドメイン駆動設計においては最後のものにあまり重きが置かれていないことを指摘した。 集合演算によるリレーションの導出(検索) ディスクへの書き込みによる永続化(蓄積) 各種制約によるデータの整合性の確保 ky-yk-d.hatenablog.com 記事では、リレーショナルデータベースの特性を改めて検討し、その特性からの帰結としてCQRSとSQLQLを位置付けてみたい。 リレーショナルモデルにおける整合性の確保 整合性の確保をリレーショナルデータベースが担うという発想は、決して新奇なものではない。リレーショナルモデルの父であるコッドの1970年の論文「A Relational Model of Data for Large Data Banks」*1でも、データの整合性(consistency)というテーマが大きく取り

    リレーショナルモデルにおける制約とCQRS・SQLQL - こまぶろ
  • flux/ReduxのStoreの持ち方について思う事 | scratchpad

    fluxもReduxもどうデータを持つかについてはあまり多く説明されてない気がします。もちろんアプリケーションによって持ち方は異なるとは思うんですが、自分用のメモとして改めて考え方を整理しておきたいと思います。 Store分割の単位:画面 vs ドメインモデル Storeを画面毎に分割すべきかドメインで分割すべきか否かという議論があると思います。個人的にはドメインモデル毎に分割して整理すべきだと考えています。過去にfluxでフルSPAを一人で開発した時は最初はある程度画面毎にStoreを分割してたんですが、すぐきつくなってきてドメインモデルで分割し直しました。 画面毎に分割すると画面が増える度にStoreを増やすことになります。しかし画面が増える度にドメインの概念やデータの種類が増えるわけではないので、この場合明らかに重複した無駄なコードを書いてる事になると思います。 もちろんアプリケーシ

  • 複雑なJavaScriptアプリケーションを考えながら作る話

    autoscale: true theme: Plain Jane,5 複雑なJavaScriptアプリケーションを考えながら作る話 自己紹介 Name : azu Twitter : @azu_re Website: Web scratch, JSer.info #jsprimerを書いています JavaScript入門書に興味ある人はウォッチ :star: :warning: 注意 :warning: 作成するアプリケーションによって必要な構造は異なります 今回の話はある程度の規模で複雑性を持つクライアントサイド ライブラリ抜きで数万LOC >= 長期的にメンテンナンスや変更が発生するアプリケーション サーバサイドレンダリングはしないクライアントアプリケーション 3行でOK 複雑なJavaScriptアプリケーションを作るにあたりドメインモデルをどう実装するか悩んだ 色々と試行錯誤した

  • ドメイン イベント: 設計と実装 - .NET

    このコンテンツは eBook の「コンテナー化された .NET アプリケーションの .NET マイクロサービス アーキテクチャ」からの抜粋です。.NET Docs で閲覧できるほか、PDF として無料ダウンロードすると、オンラインで閲覧できます。 ドメイン内での変更の副作用を明示的に実装するには、ドメイン イベントを使います。 DDD の用語を使って言い換えるなら、複数の集約に副作用を明示的に実装するには、ドメイン イベントを使います。 また、スケーラビリティを向上させ、データベース ロックの影響を小さくする必要がある場合は、同じドメイン内の集約の間の最終的な整合性を使います。 ドメイン イベントとは イベントとは、過去に発生した出来事です。 ドメイン イベントはドメインで発生する出来事であり、それを同じドメイン (インプロセス) の他の部分に認識させます。 他の部分は通知を受けると、通常

    ドメイン イベント: 設計と実装 - .NET
  • (なんとなくわかった気になれる)ドメイン駆動設計の概要 // Speaker Deck

    All slide content and descriptions are owned by their creators.

    (なんとなくわかった気になれる)ドメイン駆動設計の概要 // Speaker Deck
    sugimori
    sugimori 2017/02/06
    なんとなくどこがで使ってみよう
  • ドメイン駆動設計: Aggregate実装チェックシート - Qiita

    ドメイン駆動設計でAggregate(集約)を実装するためのチェックシートです。 □ トランザクション分析をしてトランザクションの単位でAggregateを実装しているか? 単にツリー構造や分類学的にAggregateを作っているとしたら正しくない。 Entityを複数含むAggregateを作っている場合は、トランザクション分析していない可能性があるため、 ユースケースを確認しビジネス上のトランザクション分析を行う。 □ Aggregateの大きさは大き過ぎないか? もし、Aggregateが複数のEntityを含んでいる場合は、 EntityをValue Objectにすることができないか、 直接参照ではなくEntityをAggregate Rootに昇格しIDによって参照する設計にできないかを検討する余地がある。 □ 他のAggregateは直接参照ではなく、IDによって参照されてい

    ドメイン駆動設計: Aggregate実装チェックシート - Qiita
    sugimori
    sugimori 2016/11/30
    ちょっとイメージ湧いた
  • Practical DDD #1: Specificationパターンの例

    あるエンティティに対して、何らかの条件を満たすものをグループとして扱いたいことがよくあります。安直な実装としては、条件を加味してエンティティを抽出するようなメソッドをリポジトリに追加する方法をとってしまうかもしれません。 このようにリポジトリにメソッドを持たせてしまうと、条件が集合操作の中に埋もれてしまい、再利用しづらくなります。そこでDDDではSpecification(仕様)としてこういった条件をくくり出すパターンが紹介されています。『エリック・エヴァンスのドメイン駆動設計』p.229「仕様の適用と実装」では、次のように書かれています。 仕様の価値の多くは、全く異なるように見えるアプリケーションの機能を統一することにある。以下に挙げる3つの目的のうち、1つでも当てはまれば、オブジェクトの状態を(筆者注:仕様として)定義する必要があるだろう。 オブジェクトを検証して、何らかの要求を満たし

    Practical DDD #1: Specificationパターンの例
    sugimori
    sugimori 2016/11/19
    仕様パターンってうまく使えそう
  • Scala界隈でDDDが大いに盛り上がったのでログをまとめましたよ-その2 - Kuchitama Tech Note

    昨日に引き続き、ScalaJpのgitter.imで上がったDDDの話題の続きです。 scalajp/public - Gitter なんか、昨日の記事がはてブホットエントリしたみたいで、恐縮してます。 昨日あげた2/23の話題ででDDDに関する盛り上がりは収まったかにみえたのですが、翌日、導師かとじゅんさん(@j5ik2o)がみんなの疑問に一つ一つ応えて、我々を更にDDDの世界に導いてくださいました。 実践ドメイン駆動設計 (Object Oriented Selection) 作者: ヴァーン・ヴァーノン,高木正弘出版社/メーカー: 翔泳社発売日: 2015/03/17メディア: 大型この商品を含むブログ (1件) を見る 2月24日 j5ik2o 2015年2月24日 エヴァンスのDDDだと具体的なrepositoryの置き場所に言及されてないように見える ドメインモデルのライフ

    Scala界隈でDDDが大いに盛り上がったのでログをまとめましたよ-その2 - Kuchitama Tech Note
    sugimori
    sugimori 2016/11/07
    解釈が具体的で参考になる
  • ドメイン駆動設計 基本を理解する

    2. 日の内容 • ドメイン駆動設計の「考え方」 • 「まえがき」を中心に – オブジェクト指向、エクストリームプログラミング • ドメイン駆動設計の「3つの原則」 • 1章 2章 3章から – ドメイン知識の習得、言葉による意図伝達、コードで表現 • ドメイン駆動設計の「基スキル」 • 4章 5章 6章 7章から – ドメイン層の隔離、ドメインオブジェクトの設計、総合演習 2 ※「基スキル」は、時間が足りなくなる見込み。あらかじめご了承ください。

    ドメイン駆動設計 基本を理解する
    sugimori
    sugimori 2016/11/06
    全体がまとまってるやつ
  • DevLOVE Beautiful Development( #devlove, #devlove0409, #DDDjp )参加メモ - memoの場

    DDDに関するカンファレンスへ参加した際のメモです. ■イベント名:DevLOVE Beautiful Development -Tackling Complexity in the Heart of Software ソフトウェアの核心にある複雑さに立ち向かう ■日時:2011/04/09(土) 13:00-20:30 ■場所:オラクル青山センター ■参加者数:90名位 ■資料 要項:http://kokucheese.com/event/index/9530/ DevLOVEによる動画公開:http://www.youtube.com/user/developlove @ywindishさんによるトゥギャり: 「4/9 DevLOVE Beautiful Development つぶやきまとめ」: http://togetter.com/li/122199 都元ダイスケ(@daisuk

    DevLOVE Beautiful Development( #devlove, #devlove0409, #DDDjp )参加メモ - memoの場
  • FluxとDDDの統合方法 - かとじゅんの技術日誌

    おはこんばんにちは、かとじゅんです。 久しぶりにブログを書く…。最近、趣味Angular2やらReactやらやっています。やっとWebpackになれました…。 さて、今回のお題は「FluxとDDDの統合方法」について。Angular2を先に触っていましたが、FluxといえばやはりReactだろうということで途中で浮気してReactで考えています。Angular2でもできるはずですが、今回はReactで統合方法*1について考えてみたいと思います。一つ断っておくと、FluxはDDDと統合することを想定していない設計パターンなんで云々とかはここでは考えていません。それはこのブログ記事を読む読まないに関わらずご自身で判断されてください。ソースコードについては、Githubへのリンクを一番下に書いてあるので興味がある人は参考にしてみてください。 Fluxって何? まず基礎ということで、Flux i

    FluxとDDDの統合方法 - かとじゅんの技術日誌
  • 1