ドメイン駆動設計を軽快に実践するための工夫DDD関西.java 3/5(土) 発表資料
某S社のddd(メイリオ)
2. 自己紹介 名前@kumake1004 ‒ Sansan 株式会社 アプリケーションエンジニア ‒ 2011年入社 (5年目) 仕事 ‒ 法人向け名刺管理アプリのサーバーサイド実装 ‒ アプリエンジニアとインフラエンジニアの板挟みにあうこと 興味 ‒ .NET (C#) / DDD / テスト / マネジメント 3. どうしてこうなった駆動開発とは 職場で DDD 導入したら失敗しました ‒ (個人の感想です) 再挑戦を始めたところ、、、 ‒ 漠然と思いはあって、良い機会なので振り返って言語化します ‒ という普通の失敗事例紹介 つまりただの出オチ 4. - 実践ドメイン駆動設計 コアドメイン (スクラム) における集約の使用 “彼らには DDD の経験があまりなかった。そのため、チームは DDD に関 してちょっとした間違いを犯した。” “最終的に彼らは、自分たちが集約を扱った経験を
DDD(ドメイン駆動設計)に関する資料 - きしだのHatena
ちょっとまとめ。 ドメイン駆動設計・開発の実践 Eric EvansがDDD（ドメイン駆動設計）を語る Domain-Driven Designのエッセンス -目次- ドメイン駆動設計 ( DDD ) をやってみよう DDD時代の設計 - DDD-memo エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) 作者: エリック・エヴァンス,今関剛,和智右桂,牧野祐子出版社/メーカー: 翔泳社発売日: 2011/04/09メディア: 大型本購入: 19人 クリック: 1,360回この商品を含むブログ (131件) を見る エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented SELECTION) 作者: マーチン・ファウラー,長瀬嘉秀,株式会社テクノロジックアート出版社/メーカー: 翔泳社発売日:
ドメインモデルの関連を表現するには - じゅんいち☆かとうの技術日誌
たとえばこんなモデルがあって、相互に依存しているケースを考えよう。 注意:説明を簡単にするために、varを利用しています。 従業員1 2 3 4 5 class Employee( val id: Long, val name: String, var depertment: Option[Depertment] = None ) 部署1 2 3 4 5 class Depertment( val id: Long, val name: String, var employees: Seq[Employee] = Seq.empty ) 利用例1 2 3 4 5 val employee = new Employee(1, "KATO") val depertment = new Depertment(1, "Dev") employee.depertment = Some(depertm
ドメイン駆動設計・俯瞰編・モデル「深」化 - Strategic Choice
俯瞰ドメインモデリングを継続し、リファクタリングしてモデルの価値を高めていきます。※赤がパターンです。 補足背景には常に「ユビキタス言語」「モデル駆動設計」があります。深いモデルを目指し、継続的に概念レベルのリファクタリングを行います。 見つけにくい概念として「仕様」「制約」「プロセス」があります。リファクタリングを続けていくと、モデルの価値が一気に高まる「ブレイクスルー」が起こる事があります。リファクタリングを支えている「土台」が「しなやかな設計」です。 2つの要点があります。 「抽象化」：理解を容易にして、最大限のカプセル化を行います。「分割」：適切な粒度を保ち、かつ依存関係の排除を行います。既存の「体系化された知識」も利用して、効率よく設計します。 利用できる知識には「アナリシスパターン」や「デザインパターン」などがあります。
Beautiful Development ソフトウェアの核心にある複雑さに立ち向かう - DevLOVE サイト
DevLOVE Beautiful Development Tackling Complexity in the Heart of Software ソフトウェアの核心にある複雑さに立ち向かう あなたが、もし月に向かうならば。 月に辿り着くための、乗り物が必要だ。 あなたは、月に行く用意があるか。 今 我々は、月に行くための乗り物を手に入れた。 ◆DDDカンファレンス！◆ 読む者の心を挫き、「DDD難民」という言葉を生み出した 『Domain-Driven Design』の翻訳がいよいよリリースされます。 （DDDとは） また、4月12日のQcon Tokyoでは、提唱者のEric Evans氏が来日します。 『DDD』が世に送り出されてから、8年。 今、日本のソフトウェア開発現場のキャズムを 越える、その時が来たのかもしれません。 すな
DevLoveのBeautiful Development（DDD勉強会）に参加してきました - 達人プログラマーを目指して
昨日、DevLoveの主催するBeautiful Development（ソフトウェアの核心にある複雑さに立ち向かう）という勉強会に参加してきました。 https://sites.google.com/a/devlove.org/development/past-beneficiaries/devlove_ddd2 今回は、Domain-Driven Design（DDD）をテーマにした勉強会でした。ここで簡単にレポートさせていただきたいと思います。 勉強会参加のすすめ 実は、DevLoveの勉強会に参加するのはまだ今回が2回目です。*1 このように私自身もまだDevLove初心者なのですが、今回は初参加の人がかなり大勢いたようです。*2こういった技術者の勉強会というと、初心者お断りというか、相当の予備知識があったりOSSコミュニティーに貢献したりしていないと参加してはいけないのでないかと
僕と地豆とDDD - 都元ダイスケ IT-PRESS
Domain-Driven Design: Tackling Complexity in the Heart of Software 作者: Eric Evans出版社/メーカー: Addison-Wesley Professional発売日: 2003/08/22メディア: ハードカバー購入: 4人 クリック: 113回この商品を含むブログ (89件) を見る Domain-Driven Design: Tackling Complexity in the Heart of Software というソフトウェア設計に関する本がある。 この設計の考え方は、略してDDDと呼ばれたが、同時に「DDD難民」という言葉さえも生み出したらしい。ハードカバーによる560ページ、6000円を超える、洋書である。今思えば怖い物知らずだった。知らなかったとは言え、よくもまぁこの本を手にとったものだ…。 この
イベントソーシングスタイルを実装する | システム設計日記
採用業務の状態管理の仕組みをモデリングしている。 状態管理を、イベントソーシングスタイルで、やるための、大まかなクラス構成を絵にしてみた。 それぞれのクラスの役割をできるだけ、単純明快にすることを、重視した。 関心ごとの分離（ SoC : Separation of Concerns )原則、 単一責任原則 ( SRP : Single Responsibility Principa ) をこころがけたつもり。 メッセージング ／ Web アプリケーション 上半分は、メッセージングのフレームワーク Mule ESB での実装をモデル化したもの。 下半分は、（今までやってきた） Web アプリケーションの MVC モデル、サービス層／ドメイン層／インフラ層のレイヤ構造を整理したもの。 Mule ESB のサービス部品と、Web アプリで使う Service クラスとは、完全に一致していない。
Martin Fowler: eaaDev
Development of Further Patterns of Enterprise Application Architecture When I wrote Patterns of Enterprise Application Architecture, I was very conscious of the incompleteness of the book. There is much, much more to say about enterprise application development than I could say in one book. So I've been working on capturing further patterns, with the hope that I'll put together more volumes. Progr
state ソーシング、 event ソーシング 【スタイルの選択肢】 | システム設計日記
業務の情報の扱い方の基本スタイルとして、 * state ソーシング * event ソーシング がある。 state が先か、event が先か、という正反対のスタイル。 state ソーシング 現在の「状態」を中心にしたスタイル。 state オンリー 一番、単純なパターン。 いわゆる「上書き」モード。 メモリ上のオブジェクトを、 setter とか update メソッドで、最新の状態を保持する。 更新前の状態は、どこにも残っていない。 テーブルであれば、update 文で、最新の状態に上書きしていくパターン。 もっとも単純だし、これで要件が満たせるなら、これで必要十分。 情報源は、「上書き」された最新の state だけ。 これが、state ソーシング のもっとも、単純な state オンリー パターン。 state - audit log パターン state を変更した時に、
Event Sourcing
Capture all changes to an application state as a sequence of events. This is part of the Further Enterprise Application Architecture development writing that I was doing in the mid 2000’s. Sadly too many other things have claimed my attention since, so I haven’t had time to work on them further, nor do I see much time in the foreseeable future. As such this material is very much in draft form and
ドメインモデル駆動開発の実践 | システム設計日記
今のプロジェクト「ドメインモデル駆動開発」に、こだわって、やっている。 ドメインモデル駆動開発（DMDD:Domain Model Driven Development) は、モデリングや設計よりも、実際のコードの書き方が、主要な関心事。 やり方 具体的、かつ、簡単。 基本のアイデアは、Eclipse プロジェクトを、レイヤごとに、別々に作成すること。 （１）まず、ドメイン層のプロジェクトを作って、ドメインのクラス群を作る （２）次に、データベースを定義する （３）次に、データアクセス層の プロジェクトを別に作って、ドメイン層プロジェクトを参照する。 O-R マッピング ( SQL Map ) の仕組みを使って、ドメイン層で宣言した、 Repository インタフェースを、実装する。 （４）次に、サービス層のプロジェクトを、さらに別に作る。 このプロジェクトも、ドメイン層プロジェクトを参
Home - Domain Language
About Domain Language We are a small consultancy focused on Domain-Driven Design (DDD) and led by Eric Evans, who wrote the first book on DDD. Check out DDD eLearn! Our video-based course on Domain-Driven Design (DDD) is just over 5 hours of tightly edited video. This self-guided course focuses on the deep concepts of DDD, explained by Eric Evans, author of the original book on DDD, Domain-Driven
Baseunits Library - 都元ダイスケ IT-PRESS
さて、Java Advent Calendar -ja 2010 : ATND 10日目。昨日は、id:yuroyoro でした。二日連続で真っ黒な魔術が紹介されたので、ここは真っ白で実用的な奴をひとつ。 最近Domain Driven Design（DDD）っていう設計手法が、自分の周辺一部で話題になっている。当然、賛否両論なんだけども*1、個人的には好きな考え方でして。ま、詳細は色々な方がブログに書いているので割愛します。興味あれば本読んでみましょう。洋書*2だけどｗ Domain-Driven Design: Tackling Complexity in the Heart of Software 作者: Eric Evans出版社/メーカー: Addison-Wesley Professional発売日: 2003/08/22メディア: ハードカバー購入: 4人 クリック: 113
ドメイン駆動設計やるためのチェックリスト | システム設計日記
Domain-Driven Design(DDD)１７章に、ドメイン駆動設計を、やるための、６つのチェック項目が載っている。 □ Context Map を描いてみる： Ｑ． ちゃんと描ける？ □ プロジェクトチームの「言語」： Ｑ． コードもドメインの用語が中心？ □ 重要事項の理解度： Ｑ． Core Domain を発見した？ Domain Vision Statement ある？ □ プロジェクトの技術基盤： Ｑ． 「モデル駆動設計(MDD)」向き？ or MDD の障害 ? □ メンバーのスキル： Ｑ． 「必要」なスキルセットを持っている？ □ 知的興味： Ｑ． メンバーは、ドメインを知ることに興味を持っている？ このチェックリストで、自分たちの５年前（出発点）、現在、今後の見通し（？）を、書いてみる。 Context Map をちゃんと描ける？ ■５年前 言葉すら知らなかった。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ドメイン駆動設計・俯瞰編・アプリケーション構築 - Strategic Choice
ドメイン駆動設計(DDD)の実践Part2
Beautiful Development ブレイクスルー体験記
DevLOVE Beautiful Development - 第一幕 陽の巻
