Anemic domain model - Wikipedia
The anemic domain model is described as a programming anti-pattern where the domain objects contain little or no business logic like validations, calculations, rules, and so forth. The business logic is thus baked into the architecture of the program itself, making refactoring and maintenance more difficult and time-consuming. This anti-pattern was first described[1] by Martin Fowler, who consider
ドメインロジックの実装方法とドメイン駆動設計 :: handsOut.jp
スライド1: BPStudy 第7回 2008年3月28日ドメインロジックの実装方法とドメイン駆動設計Ouobpo佐藤 匡剛http://ameblo.jp/ouobpo スライド2: もくじ・ 第Ⅰ部 ドメインロジックの実装方法・ 第Ⅱ部 ドメイン駆動設計の紹介2008/03/28 BPStudy 第7回 2 スライド3: 第Ⅰ部ドメインロジックの実装方法2008/03/28 BPStudy 第7回 3 スライド4: 3層アーキテクチャ・ エンタープライズアプリの典型的アーキテクチャプレゼンテーション層 ドメイン層 インテグレーション層アクションアクションアクションWebアプリFWサービスレイヤーPOJOPOJOPOJO POJOルールエンジンワークフローエンジンDI/IoCコンテナDAODAOインテグレーションゲートウェイデータアクセスFWシステム間統合MWFW ・・・ フレーム
相互依存性の設計・実装パターン いろいろ | システム設計日記
Repository パターンを書いた記事で、「相互依存性」について興味深いコメントをいただきました。 現実の業務アプリでぶつかる、とても重要な設計課題だと思います。 私なりの、やり方のアイデアをざっと整理してみました。 コメントいただいた内容（抜粋） > でも、「ビジネスパターンによるモデル駆動設計」にある経済減少イベントと経済増加イベントのように対等なエンティティでは、相互依存関係をどのように解決すればいいのかわかっていません。業務要件上はこの2種類のエンティティは区別されなければならないので、困ったもんだなーとｗ > BusinessIncrementRepositry > BusinessDecrementRepositry > なるものを作っても、相互依存関係は解消されないなーと。 > こういう場合の何かよいアイデアとかお持ちではないでしょうか？ 「ビジネスパターンによるモデル駆
ビジネスロジックの設計・実装 ： そこがもっと知りたいのに | システム設計日記
Domain-Driven Design(DDD)の 219ページに、 "How to Model Less Obvious Kinds of Concepts" (それほど明確でない概念をどうやってモデリングするか？) という節があります。 具体的には、ビジネスロジック、ビジネスルールを ・制約 ・プロセス（業務手順） ・仕様 というカテゴリわけで説明している。 でも、説明は、わずか４ページ。 現場で、モデリングするときの一番の悩みどころだし、参考になるネタの宝庫のはずなのに．．． エバンス、ずるい？ 著者のエバンスも、 「自分も最初は、ここらへんは、どうやったらよいかわからなかった」 「でも、この三つのカテゴリを学んでから設計がうまくできるようになった」 とか 「こういうところは、オブジェクト指向の設計・実装の現場では、良いモデルは自然にはでてこない」 「でも、こういう課題をモデリング
Martin Fowler's Bliki in Japanese - ドメインモデル貧血症
http://martinfowler.com/bliki/AnemicDomainModel.html これはずいぶん昔からあるアンチパターンのひとつですが、今になって台頭してきているようです。 Eric Evans と話したのですが、彼も、それがだんだんポピュラーになってきていることに気づいていました。 私たちほど大の「真Domain Model」推進者としてみれば、ちょっとうれしくありません。 ドメインモデル貧血症の基本的な症状は、一見、それが本物のドメインモデルに見えるという点です。オブジェクトがいくつかあり、それらはドメイン空間にある名詞から名前をつけられています。それから、オブジェクト同士がしっかりとしたリレーションで結びついており、本物のドメインモデルと同じような構造を持っているのです。 ただし、オブジェクトの振る舞いを見れば違いが分かります。それらのオブジェクトにはわずかな
ドメイン・モデル - goldenportのブログ
id:goldenport:20060508:1147055688にも書いたのだけれど、最近ドメイン・モデルに興味を持っている。 DOAからインスパイアされたこともあり、ドメイン分析段階のドメイン・モデルの具体度と設計段階のドメイン・モデルとの関係について考察を進めているのだけれど、そのような観点で『Domain-Driven Design: Tackling Complexity in the Heart of Software』をチェックしている。 ドメイン分析の段階では、ユースケース用のラフな概念モデルを作るのが汎用的な手法ではあると思うのだけれど、DOAのように最初の段階で詳細な論理モデルを作るアプローチも、企業システムというスコープで考えれば、なかなか魅力的な選択であると思うようになった。もちろんこれは、かなりの部分がパターン化できるという見込みによるものである。 Domain-
ドメインモデル管理のあらゆる側面
はじめに 『Domain Driven Design (ドメイン駆動設計)』 [Evans DDD] や『Applying Domain Driven Design and Patterns (ドメイン駆動設計とパターンの適用)』 [Nilsson ADDDP]などの本から学ぶことができるように、ドメインモデルパターン (『Domain Model pattern (Patterns of Enterprise Application Architecture (エンタープライズアプリケーションアーキテクチャのパターン) 』 [Fowler PoEAA]) をアプリケーションアーキテクチャに導入すると、数多くのメリットが約束されるが、何もせずに手に入れることはできない。 ドメインモデルの使用は、ドメインモデルクラスを作成してそれらを使用するのと同じくらい簡単だということは、めったにない。ド
DDD: subclasses & root entities
Let's say I have the typical entity Car class Car : Entity { public double MaxSpeed { get; set; } public Color Color { get; set; } /* ... */ } This entity, in my domain model, would be the root entity of an Aggregate. Now let's say I specialize cars. I create a Ferrari, and the happy owners of Ferraris like to call them by a nickname: class Ferrari : Car { public string Nickname { get; set; } } Le
DddStepbystep.com is for sale | HugeDomains
Working with hugedomains.com was a quick and easy process. We got to speak to multiple real people located in Colorado without having to wait on hold! Our only complaint was we felt we had to overpay more than this particular domain was worth, and we weren't able to negotiate it down to a level that we felt was fair. However, payment and delivery were seamless, and within a few hours we had all of
ドメイン駆動設計の概要
目次 プラトン的モデル 言うべきことを言う コンテキスト 価値提案を把握する 単一責任システム エンティティは 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
[ 技術講座 ] 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 モジ
DDD - Java EE勉強会
Menu Top JavaEE勉強会 参加するには FAQ MakingSenseofStreamProcessing MicroservicesVsSOA ModernJavaEEDesignPatterns BSA EIP DSL DDD 議事録 最新の20件2023-11-24 MicroservicesVsSOA/The World of Service-Based Architectures 2020-11-14 DDD/Knowledge-Rich Design MakingSenseofStreamProcessing/Example Implementing Twitter 2020-10-28 EIP/Aggregator 2019-12-18 EIP/Publish-Subscribe Channel 2018-06-10 FrontPage 2017-07-08 Ma
InfoQ: ドメイン駆動設計・開発の実践
ドメイン・モデルと開発に注力しないと"太ったサービス・レイヤ"と"ドメイン・モデル貧血症"によるアプリケーション・アーキテクチャになってしまいます。この場合、ファサード・クラス(通常はステートレス・セッション・ビーン)にどんどんビジネス・ロジックが溜まっていき、ドメイン・オブジェクトがgetter/setterからなる単なるデータの運び屋のようになってしまいます。このアプローチをとるとドメイン固有のビジネス・ロジックやルールが複数の異なるファサード・クラスに散在(時には重複)することになります。 "ドメイン・モデル貧血症"はたいていの場合、コストに見合いません。他の企業と比較して利点があるわけではなく、このアーキテクチャの下でビジネス要求の変化を実装するには開発と本番環境へのデプロイするのに時間がかかり過ぎます。 DDD実装プロジェクトにおけるいろいろなアーキテクチャや設計について見ていく
Time & Money Code Library
Time and Money Code Library This is a project to develop code for manipulating basic concepts in recurring domains such as time and money. The design principles followed here are explained in Part III of the book Domain-Driven Design. Read the credits here and release notes here. For some of the conceptual workings, you can read this explanation of time algebra and this explanation of interval mat
domaindrivendesign : Domain-Driven Design
This group is for discussion of the domain-driven style of designing software, and the book by Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Business Software. Questions and discussion of the book content is welcome here, as well as sharing of experiences applying DDD, and discussions of the topic in general. More information is available at http://domaindrivendesign.org
[ 技術講座 ] 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 モジ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ドメインドリブンデザインはDIやAOPなしでも十分な実装可能か？
InfoQ: Domain Driven Design（ドメイン駆動設計） Quickly 日本語版