OOじゃないDDDについて - うさぎ組
概要 モデリングについていろいろ - Togetterまとめを読んでいて、前にも何度か言ったことがあるけれど、もう一度言っておこうかー的な感じです。多分ブログには書いていませんでしたので。 端的に言えば、パイプ&フィルターパターンがアプリケーションドメインであるアプリケーションもあって、そういったものはオブジェクト指向より関数型的なほうがうまく適合する可能性もあるという話。 DDDとプログラミングパラダイムやプログラミングスタイルは直交するはずだ Eric Evansから提案されたDDDはクラスベースOOを主体とした実例が多かったわけですが、DDDという概念はOOを前提としていないと僕は捉えています。特に、ユビキタス言語、コンテキストの明示、モデリングと密接な開発といった部分は多くのソフトウェア開発において役立つと言えそうですし、おそらくはプロダクト開発全体でも言えそうです。 エンティティ
Scala界隈でDDDが大いに盛り上がったのでログをまとめましたよ-その1 - Kuchitama Tech Note
以前、ScalaJpのgitter.imでDDDについて議論が盛んに行われてたけど、いずれログが消えちゃうのがもったいなくて、ここに内容を貼付けます。 scalajp/public - Gitter 要約すると実践DDD本出たらみんなで読もうぜ。ってことで。 実践ドメイン駆動設計 (Object Oriented Selection) 作者: ヴァーン・ヴァーノン,高木正弘出版社/メーカー: 翔泳社発売日: 2015/03/17メディア: 大型本この商品を含むブログ (1件) を見る ホントは、自分のブログとかじゃなくてGistとかがいいんだろうけど、見た目を整えるのが一番楽なので、ここに掲載しておきます。 一応、最初にまとめるにいたった経緯↓ xuwei-k 2015年2月24日 gitter、無料だとログの保存期間2週間って話だったけど、実は現状全部残ってる https://gitte
実践ドメイン駆動設計 | 翔泳社
『エリック・エヴァンスのドメイン駆動設計』は、2003年の刊行だったにもかかわらず、大型ソフトウェア構築時につきまとう不透明感を払拭するための指針として現役技術者に多大な影響を与えた。ある意味、エリック・エヴァンスの先見性によって、今日、必要とされるパタン／アンチパタンが整理されていたためだ。 とはいえ、それからすでに11年。ベースとなるオブジェクト指向はそれほど大きな変革はないものの、この10年の間にコンピューティングの対象は大きく増え、さらにドメイン駆動設計をコトバでは知っているものの、経験値のまだ低い技術者の増加もあり、理論だけではなく現状に則した形で体得する必要性が増している。 本書はDDDの考え方はもちろん、コミュニティや実際のビジネスシーンのなかから実践的な方法論を精錬し、いわば21世紀（初頭）型ドメイン駆動設計を伝授するものであり、現在のニーズに合致する内容で構成されている。
Domain-Driven Design Reference Definitions and Pattern Summaries encapsulate with MODEL-DRIVEN DESIGN express model with isolate domain with encapsulate with ENTITIES VALUE OBJECTS LAYERED ARCHITECTURE AGGREGATES REPOSITORIES act as root of FACTORIES enc
Domain-Driven Design Reference Definitions and Pattern Summaries encapsulate with MODEL-DRIVEN DESIGN express model with isolate domain with encapsulate with ENTITIES VALUE OBJECTS LAYERED ARCHITECTURE AGGREGATES REPOSITORIES act as root of FACTORIES encapsulate with express model with encapsulate with access with encapsulate with access with DOMAIN EVENTS express model with SERVICES push state c
ドメイン駆動設計のリファレンス本 | GuildWorks Blog
井上です。 現在、ドメイン駆動設計(Domain Driven Desing . 以下 DDD)を用いて開発を行っています。 DDDの参考書籍といえば、もちろん「エリック・エヴァンスのドメイン駆動設計 ソフトウェアの核心にある複雑さに立ち向かう」(以下 DDD本)ですが、その著者であるエリック・エヴァンスが最近(2014/9/22)「Domain-Driven Design Reference: Definitions and Pattern Summaries」という新しい本(以下 DDDリファレンス本)を出していることに気がつきました。 DDDリファレンス本とは 早速DDDリファレンス本を取り寄せてみました。８８ページと非常にコンパクトな本になっています。 内容的には、以下で公開されているPDFに新しい図や写真を追加してペーパーバックとして出版したもののようです。 DDD REFERE
bliki: Bounded Context
Bounded Context is a central pattern in Domain-Driven Design. It is the focus of DDD's strategic design section which is all about dealing with large models and teams. DDD deals with large models by dividing them into different Bounded Contexts and being explicit about their interrelationships. DDD is about designing software based on models of the underlying domain. A model acts as a UbiquitousLa
DDDにおいて、なぜUser#saveがいけてないのか考えてみるテスト - fusatsukatsujinのブログ
数週間前にDDD勉強会（羊）に参加したのですが（なんとじゅんいち☆かとうさんがしゃべってくれました！）、なにも成果をまとめていなかったので、その後、思ったこと考えたことを、今までの読書範囲で自分なりにまとめたいと思います。 で、テーマは一点のみで、 掲題の通り、なんでUser#saveがいけてないのかです。 ドメインを永続化する場合には、Repository に対してドメインを格納するというアプローチを取り、 ドメインに自分自身を永続化する責務を割り当てないというのがDDDです。 勉強会では、「User#saveはユビキタス言語じゃないからだめ」ということでした。 ユビキタス言語として定義されていないものをドメインの責務に割り当てるのはおかしいというわけです。 でも、よくよく考えてみると、「ユーザを登録する」という文章は成立します。 ユーザを登録するという機能自体あるわけで、違和感はそんな
makopi23のブログ 「DDD本 読書会(羊) #8＋α」に参加しました
2014/2/23(日) 「DDD本 読書会(羊) #8＋α」に参加してきました。 告知サイト http://connpass.com/event/5072/ 以下の書籍をターゲットとした読書会なのです。 場所はいつもの矢向、横浜地区センターです。 参加者は11人です。初参加は1～2名かな。 今回はじゅんいち☆かとうさんによるDDDの解説があるということで、申し込み開始後、すぐ満席になりました～ 事の発端は以下のツイート参照。 @j5ik2o DDD本の読書会主催してて案件がド直球なのでお話していただきたいような・・・(参加者が通常6名ぐらいの会っすけど #DDDSheep — なおぴ！ (@naopi) 2014, 1月 23 この後、二つ返事で引き受けてくださったじゅんいち☆かとうさん！ イヤッッホォォォオオォオウ！ 主催の@naopiさんもグッジョブ！ この日は前日の京浜東北線の脱線
ドメインを巡るお話 | 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いうサービスは、目的が異なります。前者はアプリケーションのためにドメインモデルを再利用するためのものです。後者はドメインの知識
『DCI なんて面倒なだけで Service 使えばいい』への返答 - 鳩舎
NOTE: 最下部に追記があります。 よく言われる話として、 DCI なんて実装が面倒な上に夢の実装の話をしており、現実解としては Service クラスを用いて実装すればシンプルな実装になるのだから、そういったものは必要ないのだ、というご意見への返答です。 こういった批判の文脈の際、 Service クラスというのがどこの Service クラスを指しているのか、が問題なのですが、 DDD における Service ではないように思えるので、おそらく PofEAA などで語られる Service Layer などを指していると思われます(違うならそう言ってください)。 PofEAA における Service Layer(以後、 Service と呼ぶものはこの PofEAA における Service です)はドメインオブジェクトからアプリケーションロジックを切り離すことを主目的としていま
Scalaコードでわかった気になるDDD | GREE Engineering
みなさん、こんにちは。グリーのかとじゅん(@j5ik2o)です。 このエントリは GREE Advent Calendar 2013 の 18日目の記事です。よろしくお願いします。 私がグリーに入社してやっていることは、プログラミング言語 Scalaとドメイン駆動設計(以下、DDD)の布教活動です。布教活動といっても宣伝するだけでは具体性に欠けるので、実際に開発チームに入ってScalaやDDDの技術支援を行っています。本エントリでは、Scalaを用いたDDDの設計と実装をどのように行っているかを、DDDを知らない人でもできるだけわかりやすく説明したいと思います(Scalaわかっていると読みやすいですが、あんまり複雑なコードは出てこないのでなんとなく読めるのではないかと思います)。なお、DDDの実践例は他にもあります。一例だと思って読んでいただければ幸いです(先日のSNSチームでのドメイン駆
Domain Driven Design with the F# type System -- NDC London 2013
Domain Driven Design with the F# type System -- NDC London 2013 (Video of these slides here http://fsharpforfunandprofit.com/ddd) Statically typed functional programming languages like F# encourage a very different way of thinking about types. The type system is your friend, not an annoyance, and can be used in many ways that might not be familiar to OO programmers. Types can be used to represent
PHPカンファレンス2013 モデルとの向き合い方：ドメイン駆動設計体験ワークショップ スライド
DDDについての基礎、DDDの俯瞰、実践方法 ワークショップ
[ 技術講座 ] Domain-Driven Designのエッセンス -目次-｜オブジェクトの広場
［技術講座］ DDD難民に捧げる Domain-Driven Designのエッセンス 第 1 回 ドメイン駆動設計とは 第 2 回 DDDの基礎と実践 第 3 回 大規模なプロジェクトへの適用 DDDパターンカタログ パターン名 参考訳 I. Putting the Domain Model to Work Ubiquitous Language ユビキタス言語 Model-Driven Design モデル駆動設計 Hands-On Modeler 実践的モデラー II. Building Blocks of a Model-Driven Design Layered Architecture 層状アーキテクチャ Smart UI （アンチパターン） 利口なUI Entities エンティティ Value Objects 値オブジェクト Services サービス Modules モジ
もはや若くないし、頭も悪くなったから、いまテスト駆動開発(TDD)、ドメイン駆動設計(DDD)、DCIを学んでる - 石橋秀仁(zerobase)書き散らす
今年はプログラミングに再入門してます。 もはや若くないので、自分の「頭の悪さ」を受け入れて、それでも読み書きできるコードを模索してます。 ここでいう「頭の悪さ」とは、「大きなクラスや長いメソッドを理解できない」という脳のスペック的な意味です。 ぼくは二十代の頃と比べて頭が悪くなってしまったので、DDD（ドメイン駆動設計）、TDD（テスト駆動開発）、DCI（データ・コンテキスト・インタラクション）といったソフトウェア工学の成果に興味を持ってます。 抽象度の高いドメインモデリングとかプログラミングって、一見頭がよさそうに見えるかもしれませんが、むしろ（上記の意味で）「頭が悪い」人にこそ必要なんです。 頭が良かったら、もっとCPUに寄り添った高速なコードをすらすら書けるわけです。 頭が悪かったら、人間のメンタルモデルに寄り添った読みやすいコードを書くしかないわけです。 だから、一見高度で抽象的で
ScalaでDDDをはじめてみよう - かとじゅんの技術日誌
2010年も今日で終わりですが、皆様におかれましてはどのような年でしたか。 私は、この一年で「新しい技術の価値観」と「人との出会い」の二つの機会が恵まれた年でした。仕事に、コミュニティ活動に、お世話になった皆様、本当にありがとうございました。2011年も、皆様にとって良い年であることを祈っています。 さて、僭越ながら、Scala Advent Calendar jp 2010の最後を努めさせていただきます。31日になってすぐなのですが、帰省の都合で早めにエントリを投下しますm(__)m Scalaの個別のノウハウは、すでにいろいろなブログで紹介されているので、ここではScalaでDDDを始めるために必要な情報を提供したいと思います。DDDをコードで具体的に知りたい人は、以下のエントリを参照してください。DDDは設計思想なので100人のプログラマがいれば100通りの設計や実装があると思います
Symfony2ベースのユーザー登録サンプルを公開しました
2018年1月10日に開催された DCI Tokyo 1 に続き、2018年3月27日に DCI Tokyo 2 が開催されました。今回も James Coplien @jcoplien さんをお招きしてのトークセッションとなりました。会場は 株式会社ヴァル研究所 様に提供していただきました。 セッションは、前回同様 @remore さんと @ganchiku さんによる同時通訳とともに進められました。 今回のテーマはマルチパラダイムデザイン（Multi-Paradigm Design: MPD）の中核を成し、DCI / リーンアーキテクチャ（Lean Architecture）とも深く関係する 共通性／可変性分析 でした。 レポートは @smori1983 が担当させていただきます。 当日の様子は Coplien さんの許可を得て YouTube の DCI Tokyo 公式アカウントに
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Developers Summit 2014 「Play2/Scalaでドメイン駆動設計を利用した大規模Webアプリケーションのスクラム開発の勘所」
20110409_DevLOVE「Building Blocks」_都元ダイスケさん
