リアクティブDDDAWS データベースブログの記事 「Amazon DynamoDBによる CQRSイベントストアの構築」 を勝手に読み解く
「ドメイン駆動設計」の複雑さに立ち向かう
13. オブジェクト指向の「変更容易性」 (どのパラダイムでも同じだけど） • 抽象データ型／段階的な抽象化 – プログラムを人間の発想に近づけると扱いやすい • モジュラープログラミング – 独立性の高い部品に分けると扱いやすい – 関連するデータと操作は、ひとつのプログラミング単位に • メッセージング – 部品の組合せを柔軟に変更できると扱いやすい – sender/receiver/dynamic routing – Javaだとうまく実現できていないアイデア • メッセージングの考え方の参考 • Erlang, EIP:Enterprise Integration Patterns, マイクロ サービス, …
私的実践DDD、その２ - たなかこういちの開発ノート
（※前回からの続きです。） CQRSはモデリング上の本質的な課題への対応である CQRS（Command-Query Responsibility Segregation、コマンド・クエリ責務分離）の採用は、現代的なシステムではほぼ全て必然的にそこへ帰結すると考えた方がよいと思います。CQRSという用語は「実践ドメイン駆動設計」を読むまで知りませんでした。というよりも、参照系と更新系を分離して設計しようという話をDDDが言及しているとは知りませんでした。しかし、下記記事で書いたように、要求・要件の分析観点から、参照系業務ロジックと更新系業務ロジックは非対称に構築すべきという点はむしろモデリング上の本質的な課題だとの考えを持っていましたので、CQRSはすんなり理解できました。 ※下記記事を参照してください。 《業務プロセス、業務ロジックの理解と、フロントエンド−バックエンド間I/Fの詳細》
コードで学ぶドメイン駆動設計入門 〜リポジトリ編〜 - かとじゅんの技術日誌
コードで学ぶドメイン駆動設計入門 〜エンティティとバリューオブジェクト編〜 - じゅんいち☆かとうの技術日誌 コードで学ぶドメイン駆動設計入門 〜振る舞いとサービス編〜 - じゅんいち☆かとうの技術日誌 コードで学ぶドメイン駆動設計入門 〜ファクトリ編〜 - じゅんいち☆かとうの技術日誌 引き続き連投エントリ。私も来年で39歳になります。そして息子が7歳。いいおやじですが、脳は衰えないと言われています。鍛えれば鍛えたほど進化できると信じます。 ということで、リポジトリ編に入ります。 リポジトリ リポジトリは、ライフサイクルの途中から最後にフォーカスし、オブジェクトの永続化と永続化されたそのオブジェクトを検索する手段を提供するオブジェクトです。このように説明すると、DAOに近い印象を持つかもしれませんが、DAOはRDBMSやSQLなどのインフラストラクチャ層の関心事を含んでいるので、ここでは
これって、ドメイン駆動設計？
エリックのDDD本を読んで30分で挫折した僕が考える、こーゆーことをやるのがドメイン駆動設計なるものなんじゃないの、という資料です。Read less
実践的な設計って、なんだろう？
Devlove 名古屋 2014-5-18 DDD, Object Oriented Design, ドメイン駆動設計 オブジェクト指向設計Read less
Practical DDD #2: 責務のレイヤーとPolicy-Control-Operation
2014年4月6日に大阪で開催された第4回ドメイン駆動設計読書会＠大阪に参加しました。読書会の内容のまとめなどはWikiの方をご参照ください。今回は第1章の知識のかみ砕き、深いモデルと第2章ユビキタス言語の前半を読み、ディスカッションしました。ディスカッションで得られた気付きとこれまでに私が考えていたこと、ドメイン駆動設計の後半に出てくる「責務のレイヤー」などとのつながりについて、考察してみます。 モデルの「深さ」とは何かモデルに対して深いのか浅いのかについて、ドメイン駆動設計で何か客観的な指標が示されているわけではありません。あくまでエヴァンス氏の主観でしかないと言えますし、開発者が取り組んでいるドメインやコンテキストに依存するものでもあります。ドメイン駆動設計においては、モデルの深さを探求していくことが大きな目標の1つとされており、「深いモデル」という言葉が開発者同士の共通語になっては
コードで学ぶドメイン駆動設計入門 〜エンティティとバリューオブジェクト編〜 - かとじゅんの技術日誌
先日、DevLOVEで発表した「コードで学ぶドメイン駆動設計入門」ですが、入門としながらも難しかったかもしれません。モデリングの話は難しい方の話題なので仕方ないのですが、できるだけわかりやすく補足するブログを書いてみたいと思います。 まず、レイヤードアーキテクチャの話ですが、こちらのスライドを参照してください。 DEVLOVE HangarFlight で話したスライド&ソースコード - じゅんいち☆かとうの技術日誌 平たく言うと、そのアプリケーションが解決する問題の領域がドメインです。ドメインとそれ以外のものをごっちゃにしないようにしたのが、ドメイン駆動設計だと考えればよいと思います。 一般的に業務システムでは、対象業務がドメインに成り得ますので、ドメインは業務に準えて語られることが多いと思います。ドメインに登場する概念をユビキタス言語*1として定義し、モデルに落としこむというのが設計の
traitで簡単にDCIを実装する - じゅんいち☆かとうの技術日誌
モデルの表現方法の一つとしてDCIの実装方法を、いろいろと模索しています。 暗黙的型変換と型クラスを使ったDCIがよいと説明しましたが、traitだけでもっと簡単に実現できないか考えてみました(この方法はLean Architectureにも紹介されている実装方式です)。 traitで仕様を表現する traitは、仕様を表現するためのインターフェイスとしても使えるし、他のクラスなどに合成するための、再利用可能な実装(部分クラスなどと言われることがある)としても使えます。 DCIとは直接関係ない話ですが、まずtraitのインターフェイス的な使い方からいきます。 では、お決まりの銀行口座で説明(好きやなーw)。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 // 銀行口座エンティティ // 不変条件: 残高の量は負数であってはならな
ドメインを巡るお話 | Uzzu::Blog
Jan 4 2014Tags: dci ddd 昨年末にだらだらDCIに関する自分の考えを整理したくて身内で話していて、 結論としては「DDDとDCIどちらもメンタルモデルに近づけるために機能してる点は変わらない。その先DDDあるいはDCIをフレームワークにするか、あるいは一部に取り入れるのか、そこは取組むドメインによって取捨選択だよね」というところに落ち着いたのだけれど、勿体無い内容な気がするので改めてブログに書くことにする。 DDD脳から見たDCIの考察 DCIはFATなドメインモデルに対するアプローチというよりは、シナリオを明確にするためのアプローチなのかなと思う。 DDDを実践するような複雑な問題に直面した時、ドメインモデルは山のように増える。より知識を噛み砕いてドメインモデルにしたほうがより上層のロジックが簡潔になるので積極的にドメインモデルに落とし込む方がよく、結果として、シナ
ServiceとDCIについて - じゅんいち☆かとうの技術日誌
面白そうなネタがあったので、自分なりの考えをまとめてみる。 Ruby/Rails 用 DI コンテナ Dee をつくった、あるいは Ruby のカルチャーについて この記事はRuby用のDIコンテナの話題なんですが、DCIについても言及されているようです。比較軸はDIそのものというより、サービスとDCIだと思うので、それについてダラダラといくつか考えをまとめてみます。多分も返事になるようでならないかも。それと宗教上の都合でDDDの視点から書きます…。 サービスという言葉はあいまい まず、簡単に前提の整理から。単に”サービス”って言葉が何を指すのか結構曖昧です。 サービスは簡単にいうと手続きとか振る舞いのことですが、細かくいうと、PofEAAでいうサービスと、DDDいうサービスは、目的が異なります。前者はアプリケーションのためにドメインモデルを再利用するためのものです。後者はドメインの知識
Domain Driven Design | UREILESS
オブジェクト指向でWEBアプリケーションを作る オブジェクト指向的な設計でWEBアプリケーションを作ってみたので、そのご紹介。 これからオブジェクト指向を勉強する方や、どうすればオブジェクト指向のやり方でWEBアプリケーションが作れるのか知りたいと思っている方の参考となれば幸いです。 作ったアプリケーションは簡単なショッピングサイトです。 ショッピングサイトデモ 管理サイトデモ ソースコード（Java）：myshopj ソースコード（PHP）：myshopp（途中） はじめに いきさつ 参考書籍 ドメインモデリング モデルの状態を変化させる責任はハンドラに持たせる Based on 契約による設計（Design By Contract） リポジトリパターン リポジトリとUnit of Workパターン できるだけ不変オブジェクトにしよう リポジトリ実装クラスへ直接の依存性をもたない 通
Scalaコードでわかった気になるDDD | GREE Engineering
みなさん、こんにちは。グリーのかとじゅん(@j5ik2o)です。 このエントリは GREE Advent Calendar 2013 の 18日目の記事です。よろしくお願いします。 私がグリーに入社してやっていることは、プログラミング言語 Scalaとドメイン駆動設計(以下、DDD)の布教活動です。布教活動といっても宣伝するだけでは具体性に欠けるので、実際に開発チームに入ってScalaやDDDの技術支援を行っています。本エントリでは、Scalaを用いたDDDの設計と実装をどのように行っているかを、DDDを知らない人でもできるだけわかりやすく説明したいと思います(Scalaわかっていると読みやすいですが、あんまり複雑なコードは出てこないのでなんとなく読めるのではないかと思います)。なお、DDDの実践例は他にもあります。一例だと思って読んでいただければ幸いです(先日のSNSチームでのドメイン駆
リーンなコードを書こう：実践的なオブジェクト指向設計
10. コードを改善する機会 • 変更が必要になった時 – ビジネスルールの変更 – 機能の追加 • 変更がやりやすいように、コードを改善してから 変更する • 小さな変更依頼が良いチャンス – 変更の目的が明確 – なぜその変更がたいへんか、原因がわかりやすい – 改善の before/after を確認しやすい • 変更するたびに、小さな改善を累積していく • 大きなブレークスルーが起きる 11. まずはコードの整理 • 今回の変更に関係するコードとそうでない コードを分ける – 機能の変更はしない – コードを分ける基本手段はメソッド • 今回の変更の対象となるデータとその操作だ けを集めた部品（メソッド）を作る – 「メソッドの抽出」リファクタリング – IDE を使いこなす – 「リファクタリング」で復習する • 関係するクラス、すべてでこれを繰り返す – 現在の機能が動いている
和田卓人さん出題のテスト駆動開発問題『現在時刻とロケールに依存するテスト』をPHPを使ってオブジェクト指向で解答してみました #php #object_oriented｜CodeIQ MAGAZINE
テスト駆動開発の巨匠・和田卓人さんからの『現在時刻とロケールに依存するテスト』問題をPHPメンターズの後藤秀宣さんが解答してくださいました！ この記事は、その後藤さんによる解答コードの公開と解説記事になります！！ by CodeIQ運営事務局 PHPメンターズの後藤です。 和田卓人さん出題の『現在時刻とロケールに依存するテスト』問題をPHPを使ってオブジェクト指向のアプローチで解答してみました。 ※問題文については、和田卓人さんの解説記事を参照にしてください。 https://codeiq.jp/magazine/2013/11/1475/ 解答例は次の環境で作成しています。 PHP 5.5.4 PHPUnit 3.7 Composer サンプルコードのリポジトリをGitHubにて公開しています。コミットログなど合わせてご参照ください。（解説中にも各コミットへのリンクを貼ってあります） g
肥大化したActiveRecordモデルをリファクタリングする7つの方法（翻訳）
更新情報: 2013/11/19: 初版公開 2021/01/08: 訳文見直し、追記 こんにちは、hachi8833です。今回は、自分が知りたかった、Active Recordモデルのリファクタリングに関する記事を翻訳いたしました。1年前の記事なのでRails 3が前提ですが、Rails 4以降でも基本的には変わらないと思います。リンクは可能なものについては日本語のものに置き換えています。 なお、ここでご紹介したオブジェクトは、app以下にそれぞれ以下のようにフォルダを追加してそこに配置します。 注記: 以下は使われそうなフォルダを列挙しただけであり、実際にはこの一部しか使いません。 Value Object Service Object Form Object Query Object View Object Policy Object Decorator ⚓ 肥大化したActive
DDD with Symfony2: Basic Persistence & Testing
After having described a decent folder structure and made things clear about DDD and this series, I will continue to bootstrap the sample application, focusing on a basic persistence layer and testing. It is not tied to DDD but it is worth writing about these two points. A basic persistence layer is a layer that is simple. In other words, it does the job, period. It has poor performances, but it d
「オブジェクト設計エクササイズ -チームモデリングで学ぶドメイン駆動設計-」に参加しました
10月5日(土)にLearning Community Factory主催で開催された「オブジェクト設計エクササイズ -チームモデリングで学ぶドメイン駆動設計-」に参加しました。 オブジェクト設計エクササイズ -チームモデリングで学ぶドメイン駆動設計-講師は増田亨さん(@masuda220)です。これまでに第1回(オブジェクト設計エクササイズ -コードで覚えるオブジェクト設計-)、第2回(オブジェクト設計エクササイズ -モデルとコードで学ぶ責任駆動設計-)と開催されたオブジェクト設計エクササイズシリーズの3回目ということでした。私はこの回が初めての参加でした。 内容と感想最初に増田さんからドメイン駆動設計についての基本的な考え方を簡単に説明いただいた後、モデリングのお題が発表され、そのお題のドメインモデリングを行うといったものでした。4名〜6名、ほぼその場で初めて出会う人がチームになって、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IT-Benkyoenkai_2015-04-25_01Goto.pdf
ドメイン・フレームワークのススメ(第1回)
