昨日飲みながらドメイン駆動設計（以下、DDD）についてしゃべっていて思ったことを書く。 ドメイン駆動設計（DDD）って？ DDD とは何かという説明についてはぐぐったらたくさん出てくると思うので割愛。 Wikipedia の引用だけしておきます。（雑） ドメイン駆動設計 - Wikipedia ドメイン駆動設計（英: Domain-driven design, DDD）とはソフトウェアの設計手法であり、'複雑なドメインの設計はモデルベースで行うべきであり'、'また大半のソフトウェアプロジェクトではシステムを実装するための特定の技術ではなくドメインそのものとドメインのロジックに焦点を置くべき'とする。この名称は Eric Evans が同名の著作で用いた。 興味がある人はこちらを読んでください。 エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェ
新機能 バウチャーによるイベント管理機能をリリースしました。協賛企業の社員や関係者のイベント参加を円滑にすることに活用いただけます。詳しくはヘルプページをご覧ください。 新機能 connpass APIに新しく、所属グループを取得できるAPIやユーザーの参加イベントAPIを追加しました。各APIの詳細な仕様や利用方法につきましては、 APIリファレンス をご確認ください。またAPI利用希望の方は connpassのAPI利用について をご覧ください。 お知らせ 2024年9月1日より、connpassではスクレイピングを禁止し、利用規約に明記しました。以降の情報取得にはconnpass APIをご利用ください。APIご利用についてはヘルプページをご確認ください。
Symfony Advent Calendar JP 2012 - Day 3 ドメイン駆動設計にしたがってドメインモデルをソフトウェアとして表現するのにエンティティが使われます。エンティティは、ドメイン駆動設計におけるモデル駆動設計パターンの1つに分類されます。 賢すぎるエンティティはアンチパターンRuby on Rails由来のアクティブレコードと直結したMVCフレームワークでは、本来エンティティとして扱われるべきクラスを「モデルクラス」と呼び、そこにビジネスロジック等を実装することが推奨されていました。これらのフレームワークでは、自らモデルレイヤー部分もカバーしておきながら、すべてをエンティティとして実装することを強いるため、ドメインモデルの実装にはほとんど自由度がありませんでした。 このスタイルに慣れてしまうと、ピュアなクラスでドメインレイヤーを実装できる状況においても、誤った設計
Specificationの話です。 SpecificationはDDDのパターンの一つですが、JPA2から導入されたCriteriaを利用して、Spring Data JPAではSpecificationパターンみたいなことが出来ます。 Specificationを使用するにはリポジトリの定義でJpaSpecificationExecutorを継承する必要があります。 public interface EmpRepository extends JpaRepository<Emp, Long>, JpaSpecificationExecutor<Emp> { //.. JpaSpecificationExecutorに定義されているメソッドは以下のようなもの。 T findOne(Specification<T> spec); List<T> findAll(Specification<
レッツゴーデベロッパー2011での発表原稿とスライド 導入 2011年05月28日「レッツゴーデベロッパー2011@仙台」が開催されました。このイベントのテーマは「共有と交流」。"「共有」には、最新技術、知識、復興への想い、それぞれの決意を共有することを、「交流」には、東北と東北圏外のデベロッパーやコミュニティ同士の交流を深めることを込めて。" このイベントにてDDDセッションに登壇させて頂きましたので、そのときの発表原稿とスライドを公開致します。なお、当日はワークとして参加者の方にペアモデリングを行って頂きましたが、このドラフトではその部分を割愛しています。 スライドはこちら また映像はこちらで公開して頂いています。 さて今年4/9にDDD日本語版が出版されました。それから２ヶ月弱、翔泳社様から、はやくも増刷のお知らせを頂きました。多くの方々とおかげと深く感謝しています。さて、この増刷が
MODULESグルーピングのモデリング別名パッケージ（PACKAGES）俯瞰図所属するストーリの俯瞰図です。アプリケーション構築どういうこと？モデルもコードも意味のある単位に分割し、モジュールとしてまとめます。プログラミングの場合と同じく、モデルのモジュール分割においても高凝集・低結合が重要な目安になります。関連し合う概念同士はひとつにまとめ（高凝集）、かつ一度に考えなければいけない範囲は最小限にします（低結合）。どうして？モデルも分割統治モジュールに分割されるのはコードだけではありません。概念も分割されます。モジュール内では高凝集、モジュール間では低結合が必要です。人が一度に考えられる物事の数には限りがありますし（ゆえに低結合)、首尾一貫していない思考の断片は理解するのが難くなります（ゆえに高凝集)。モジュールもモデルモジュールも、モデルの一部です。モデルを表現し、深化させなければなりま
UBIQUITOUS LANGUAGEドメインモデルを至る所にどういうこと？ドメインを正しく捉えた価値の高いソフトウェアを設計するには、ドメインモデルを使用した、チームの「共通言語」が不可欠です。共通言語は、「ドメインエキスパート」「開発者」といった関係者、「モデル」「コード」といった成果物すべてに至り、同じ意味で理解されるユビキタス*1な言語です。ドメインモデルがユビキタス言語となるようにし、ドメインモデルを介してプロジェクトが一体となるようにします。どうして？共通言語がない場合、以下のような不都合が発生します。コミュニケーション断絶ドメインエキスパートが独自の専門用語を使用するのに対して、開発者もソフトウェア設計の観点から独自の言語を持っています。こうした言語の間には断絶があるので、ドメインエキスパートは欲しいものを曖昧にしか記述しません。開発者は、よく知らないドメインを理解するのに時
ドメイン駆動設計とは、要するに「どういったことなのか」を定義します。言葉の定義まず、理解しておかなければならない言葉を定義します。ドメインユーザが知識を持ち、 影響を与え、 活動する領域のことです。「業務領域」「事業対象」「問題領域」とも呼ばれます。ソフトウェア開発の文脈では、ソフトウェアがそもそも解決しようとしている関心事を指しています。モデルある状況についての、概念の明示的な「解釈」のことです。ソフトウェア開発の文脈では、ユーザの知識を、ソフトウェアに写し取るための表現したものを指しています。具体的には、（UMLなどモデリング言語の）図を指すことが多いですが、実はその限りではなく、自然言語やソースコードも含まれます。ドメインモデルそのドメインについて、モデリングした成果物のモデルのことです。モデリングモデルを作る行為のことです。『エリック・エヴァンスのドメイン駆動設計』は「ドメインモデ
DevLOVE Beautiful Development Tackling Complexity in the Heart of Software ソフトウェアの核心にある複雑さに立ち向かう あなたが、もし月に向かうならば。 月に辿り着くための、乗り物が必要だ。 あなたは、月に行く用意があるか。 今 我々は、月に行くための乗り物を手に入れた。 ◆DDDカンファレンス！◆ 読む者の心を挫き、「DDD難民」という言葉を生み出した 『Domain-Driven Design』の翻訳がいよいよリリースされます。 （DDDとは） また、4月12日のQcon Tokyoでは、提唱者のEric Evans氏が来日します。 『DDD』が世に送り出されてから、8年。 今、日本のソフトウェア開発現場のキャズムを 越える、その時が来たのかもしれません。 すな
Ryo Asai @ryoasai74 なるほど。P157「一般的に言えることだが、使っているフレームワークとは争わないこと。フレームワークと対立してしまった時には、ドメイン駆動設計の基本を保ちながら、詳細は捨て去る方法を模索すること。」#DDDjp 2011-04-30 20:20:19 Ryo Asai @ryoasai74 P160「データベースをオブジェクトの格納先として見る場合には、マッピングツールの能力に関わらず、データモデルとオブジェクトモデルをかけ離れたものにしてはならない。」これは読み落としてはならないことですね。モデルと実装を結びつけ、無駄な間接層による複雑さを避けるべき。#DDDjp 2011-04-30 21:01:35
「Domain-Driven Design」通称「DDD」の原著が出版されたのは、2003年のことだった。Kent Beck氏が賛辞に寄せた「思慮深いソフトウェア開発者全員の必携書」という言葉が示している通り、英語圏では圧倒的な支持を集め、出版から7年が経過した現在でも、Yahoo! Groupsのメーリングリストでは活発な議論が交わされている。 一方、日本では少し状況が異なる。識者の間では、有用な書籍として早くから知られていたものの、500ページ超という厚さと、文体の難しさが、多くの日本人エンジニアの挑戦を阻んできた（邦訳も待ち望まれたが、長い間出版されなかった）。 佐藤匡剛氏による「Domain-Driven Designのエッセンス」、徳武聡氏による「DDD Quickly 日本語版」をはじめ、日本語の情報は少なからず存在したし、国内での実践事例も徐々に蓄積されていたものの、本質的に
書籍「エリック・エヴァンスのドメイン駆動設計」にある全パターンを、３枚の俯瞰図にまとめます。ボリューミーなこの本を攻略するのに、この本自身にある「大規模な構造（第16章）」という戦略に倣おうと考えたからです。巨大なシステムに包括的な原則がなく、そのせいで各要素を解釈する際に、設計全体にまたがるパターンにおいてどのような役割を果たすかという観点から考えることができなければ、開発者は「木を見て森を見ず」になってしまう。全体の詳細を徹底的に調べなくても、全体の中で個々の部分が果たす役割を理解できる必要があるのだ。「大規模な構造」は、システムをおおよその構造から議論し、理解できるようにするための言語である。第16章 大規模な構造 P447-448「パターン」の仔細を見る前に、各々の「コンテキスト」の中での「立ち位置」をわかっておいたほうが、理解が「速い」し「深まる」と思います。まず「全体における部
ソフトウェアの核心にある複雑さに立ち向かう、準備をしてきた
今日は強風と雨にさらされながらDevLoveコミュ主催のDDD(Domain-Driven Design)カンファレンスへ行ってきました。 Beautiful Development ソフトウェアの核心にある複雑さに立ち向かう Eric Evans著書の『Domain-Driven Design』翻訳リリースを記念したカンファレンスとのこと。 恥ずかしながらほとんど予備知識なしで1人で参加するんのは少々心もとなかったのですが、「え〜いっ」ってな感じで会場へGo。 2トラック構成のカンファレンス DDD本の構成にそった書籍内容紹介を主とした「陽の巻」 DDDを用いた開発実例など応用、実践的な内容の「陰の巻」 以上の2トラック×4枠の講演でした。 私は全編「陽の巻」を拝聴させていただきました。 講演内容 手短にですが、本日のカンファレンスの流れをひととおり オープニンング PAPANDさんによ
QCon Tokyo 2011に参加しました。 Keynoteを発表してくださったDDD InventorのEric Evansさんはとてもゆったりした話し方をされる方でした。DDDの一部分を語られていましたが、一つ一つの詳細を聞いてみたくなります。 Evansさんの発表で気になったのが「Model Exploration Whirlpool」と「Bounded Context」というキーワード。DDD本をまだ読んではいないのですが、「Model Exploration Whirlpool」についてはWebに資料（PDF）あったので少し読んでみました。（以下、適当訳） Code Probe（コードを綿密に調べる） ・テストとしてのコードシナリオ ・厳密さの追加 ・言語を洗練する ・解決方法を探求する ・ミスを生み出す Challenge Model ・新しいシナリオをもって挑む Scena
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（ソフトウェアの核心にある複雑さに立ち向かう）という勉強会に参加してきました。 https://sites.google.com/a/devlove.org/development/past-beneficiaries/devlove_ddd2 今回は、Domain-Driven Design（DDD）をテーマにした勉強会でした。ここで簡単にレポートさせていただきたいと思います。 勉強会参加のすすめ 実は、DevLoveの勉強会に参加するのはまだ今回が2回目です。*1 このように私自身もまだDevLove初心者なのですが、今回は初参加の人がかなり大勢いたようです。*2こういった技術者の勉強会というと、初心者お断りというか、相当の予備知識があったりOSSコミュニティーに貢献したりしていないと参加してはいけないのでないかと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
