InfoQ: Domain Driven Design（ドメイン駆動設計） Quickly 日本語版Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
ドメイン駆動設計の概要
目次 プラトン的モデル 言うべきことを言う コンテキスト 価値提案を把握する 単一責任システム エンティティは ID とライフサイクルを持つ 値オブジェクトは記述する 集計ルートによりエンティティを結合する ドメイン サービス モデルの主要な操作 リポジトリにより集計ルートを省略する データベースの関連事項 DDD の使用を開始する ドメイン駆動設計 (DDD) とは、洗練されたオブジェクト システムの設計に役立つ原則とパターンをまとめたものです。設計に DDD を適切に適用することで、ドメイン モデルと呼ばれるソフトウェア抽象化を実現できます。このモデルにより複雑なビジネス ロジックをカプセル化できるため、実際の業務とコードとの間に存在するギャップを小さくすることができます。 この記事では、DDD に関連する基本的な概念と設計パターンについて解説します。機能豊富なドメイン モデルを設計し
DDD Sample Application - Introduction
Cargo freighter passing under the Golden Gate bridge in San Fransisco. Image courtesy of FreeFoto.com. One of the most requested aids to coming up to speed on DDD has been a running example application. Starting from a simple set of functions and a model based on the cargo example used in Eric Evans' book, we have built a running application with which to demonstrate a practical implementation of
モデル駆動ソフトウェア開発のためのベストプラクティス
それでは、実際のベストプラクティスはどのようなものか?2つのバリエーションがあって、うまい具合に一緒に使うこともできる。まず生成したコードに別のディレクトリを準備すべきである。(通常は src-gen)こうすれば生成したコードと生成していないコードの物理的な分離ができる。さらに、すべての生成した成果物は、「// WARNING! GENERATED CODE, DO NOT MODIFY」のようなコメントで始めるべきである。完璧主義の人は、そのコードがどのテンプレートで生成したかを追記してこれを補うかもしれない。どちらのオプションも、IDEの中で生成したファイルと生成していないファイルを区別するのに使うことができる。 生成したコードをチェックインしない 生成したコードはチェックインすべきではない。それはJavaのバイトコードや他の派生した成果物をチェックインすべきではないのと同じ理由である
『DIコンテナとドメインモデルの相性の悪さ』
Seasar、SpringなどのDIコンテナを使っていると、ドメイン層の実装はデータ（Entity／Dto）と振る舞い（Service／Logic）に分ける、いわゆるトランザクションスクリプトのスタイルになりがちだ（参照(1)、(2)）。理由は、1つにはドメインモデルの設計／実装そのものの敷居が高いこともあるが、そのハードルを乗り越えても、DIコンテナそのものがドメインモデルと馴染みにくい側面があるからだと思われる。 DIコンテナはエンティティやDTOにDIできない その側面とは、次の通り。DIコンテナは設計思想からしてファクトリの役目をするものであるため、DIコンテナを使う場合、インスタンスの生成は基本的にDIコンテナが担当することになり、コンポーネントに必要なオブジェクトはすべてDIで渡されるような設計に誘導されてしまう DIを使ったWebアプリケーションのアーキテクチャは、まずリクエ
『[お知らせ] S2DomainModel リリース』
S2DomainModel 0.1をリリースしました。S2DomainModelは、Seasar2でドメインモデルやDDDの実装をサポートするためのライブラリです。 http://ouobpo.sourceforge.net/s2domainmodel/ 前回のエントリ「DIコンテナとドメインモデルの相性の悪さ」で書いたとおり、ドメインモデルの中で直接生成されるドメインオブジェクト（= Entity + Logic）に他のオブジェクトをDIすることは設計上難しく、ドメインモデルの自由な設計が阻害されてしまいます。そのため、DIコンテナを使った開発では、リッチなドメインモデルは敬遠されがちです。 S2DomainModelは、この相性問題を解決するためのライブラリです。ドメインオブジェクトにDIできる仕組みを提供することで、DIコンテナを使った、より自由なドメインモデル構築を可能にします。
Martin Fowler's Bliki in Japanese - Evansの分類
http://martinfowler.com/bliki/EvansClassification.html Eric Evansのエクセレントな著書『Domain Driven Design』では、 我々がしばしば目にする様々なドメインオブジェクトが以下のように分類されている。 エンティティ：アイデンティティを持ち、時間経過によって形を変えるオブジェクト。「リファレンスオブジェクト」とも呼ばれることがある。 バリューオブジェクト：属性の組み合わせに意味があるオブジェクト。同じ値（バリュー）を持つ2つのバリューオブジェクトは、どちらもすべての属性が等しいと見なされる。バリューオブジェクトについては、私もP of EAAで触れている。 サービス：ドメインにおける独立したオペレーション。サービスオブジェクトは1つ以上のサービスを持つ。実行文脈におけるサービスオブジェクト型のインスタンスは、通常
いまさらきけない「ドメインモデル」と「トランザクションスクリプト」 - ひがやすを技術ブログ
このネタは、私自身も何度も書いてきたけど、結局意味のある結論になったためしがありませんが、再度考え直してみたいと思います。 「ドメインモデル」と「トランザクションスクリプト」をすごく簡単に説明すると、トランザクションスクリプトとは「アクションより起動される一連の手続き」、ドメインモデルとは「ドメイン内の名詞によって体系化されたモデル」です。 トランザクションスクリプト派は、「トランザクションスクリプトの方が書くのが簡単だし、業務アプリケーションにオブジェクト指向は、ほとんど必要ない」といいます。 それに対し、ドメインモデル派は、「ドメインモデルはオブジェクト指向を生かすことができるのでメンテナンス性が良い」と主張します。 ずっと平行線のままですね。 私は一番最初に「ユースケースと一対一にサービスクラスを設け、ビジネスロジックはサービスクラスに記述する」という主張をしてました。 記念すべき(
『ドメインロジックの実装方法とドメイン駆動設計』
以前一緒にお仕事をさせていただいたこともある、ビープラウドの佐藤治夫さんが主催の勉強会BPStudy 第7回にて、発表の機会をいただいたので話してきました。発表テーマは「ドメインロジックの実装方法とドメイン駆動設計」です。 http://www.beproud.jp/bpstudy/17/bp-study-7 後ほどBPStudy勉強会のサイトでも発表資料が公開されると思いますが、こちらにもUPしておきます。（アメブロではSlideShareやhandsOutのスライドを直接貼れないようなので、ちょっと変な貼り方をしています） http://handsout.jp/slide/371 以下の二部構成でお話ししました。Ⅰ. ドメインロジックの実装方法 Ⅱ. ドメイン駆動設計の紹介 前半は、お馴染みの「トランザクションスクリプト vs. ドメインモデル」の話です。それぞれのサンプルコードを交え
『DDDについての覚書』
少し前のことだが、.Net Rocks! というオンライントークショーのサイトに『Domain-Driven Design』の著者Eric Evansのインタビューが上がっていたので、今になってiPodに入れて通勤の行き帰りに聴いている。 http://www.dotnetrocks.com/default.aspx?showNum=236 インタビューの中で非常に印象的だったポイントを2つ、覚書として書いておきたい。 - DDDだからといって、全部ドメインモデルで構築するものだと思い込むのは間違い - 重要なのは、開発手法としてのアジャイルではなくて、ビジネス本来のアジャイルさ（変化のスピード）についていくこと Martin Fowler, Eric EvansDomain-Driven Design: Tackling Complexity in the Heart of Softwa
[ 技術講座 ] Domain-Driven Designのエッセンス 第1回｜オブジェクトの広場
DDD難民に捧げる Domain-Driven Designのエッセンス 第1回 ドメイン駆動設計とは 株式会社オージス総研 アドバンストモデリングソリューション部 佐藤 匡剛 Domain-Driven Design Tackling Complexity in the Heart of Software Eric Evans 著 Addison-Wesley, 59.99ドル 560ページ ISBN: 0-321-12521-5 「ドメインモデリング」は、アプリケーション開発において最も重要な部分だとされています。しかしその割には、フレームワークの使い方やアーキテクチャの設計方法など技術に関する解説書はたくさんあるものの、ドメインモデリングそのものを扱った書籍はほとんど無かったと言ってもいいでしょう。Eric Evansの『Domain-Driven Design』（以降DDD）は、「
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
オブジェクト・リレーショナル・マッピング - ユーザのケーススタディ
Domain Driven Design and Development In Practice
Domain Driven Design読書会 - ひがやすを技術ブログ
Domain Driven Design Quickly
Domain Driven Design
ドメインモデル管理のあらゆる側面
ドメインドリブンデザインはDIやAOPなしでも十分な実装可能か？
今日のDDDの重要性についてEric Evans氏に聞く
汎用言語とドメイン特化言語を組み合わせたモデルドリブンエンジニアリング