[技術講座] 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 モジ
DevLOVE Beautiful Development Tackling Complexity in the Heart of Software ソフトウェアの核心にある複雑さに立ち向かう あなたが、もし月に向かうならば。 月に辿り着くための、乗り物が必要だ。 あなたは、月に行く用意があるか。 今 我々は、月に行くための乗り物を手に入れた。 ◆DDDカンファレンス!◆ 読む者の心を挫き、「DDD難民」という言葉を生み出した 『Domain-Driven Design』の翻訳がいよいよリリースされます。 (DDDとは) また、4月12日のQcon Tokyoでは、提唱者のEric Evans氏が来日します。 『DDD』が世に送り出されてから、8年。 今、日本のソフトウェア開発現場のキャズムを 越える、その時が来たのかもしれません。 すな
この記事はJohan den Haan氏のブログ記事「http://www.theenterprisearchitect.eu/archive/2008/04/15/combining_general_purpose_lang」を、氏の許可を得て翻訳したものです。(原文公開日:2008年4月15日) モデル駆動エンジニアリングに関する以前の記事で、私はMDEの基本的な原則は「全てがモデルである」ということだと述べた。モデルとその要素にはファーストクラスの地位が与えられている。本質的な違いは、モデルがもはやプログラマのための単なるドキュメントとして使用されるだけではなく、ソフトウェア開発を駆動させるために直接利用できるということだ。モデルは、実装、変換、ソフトウェア成果物の諸相、システムに関する視点などを定義するのに用いられる。この記事で、私はモデルとは何なのか(モデルに関する様々な利用シナ
日本のオラクル・コミュニティが一堂に会するプレミア・イベントにぜひご参加ください。新しいスキルを身に付け、業界エキスパートと交流し、複雑なビジネス課題を解決するためのソリューションを発見しましょう。
システムの中核となるドメインモデルを設計します。ここでは、「システムが何をするか」といった視点から入るではなく、 「システムが対象としているもの」に着目して開発を進めます。システムの画面イメージなどは描いても良いですが、そ れはあくまでドメインの設計を手助けするものであり、ここではまだ決定しません。 まずは全体的な構成を考察します。ブログがいくつかのブログ記事を持ち、さらにブログ記事が複数のコメントを持つと 考え、次のような概念クラス図を描きました。 Blog それでは、ブログのドメインモデル Blog から考察します。ブログはその所有者やアクセス制御を持つ資源と考えられますから、AbstractResource を継承することにしました。同時に、このオブジェクトがドメインモデルであることを表す Domain 、 永続化可能であることを表す Serializable 、 ドメインオブジェク
ドメインモデルのどこかに「問題の核心」がある。 問題領域の中の「核心」の問題領域が、Core Domain。 Domain の中の Domain ですね。 Core Domain を発見し、そこに切り込んでいくのは、もっとも優秀なメンバーたちにやらせる。 開発パワーを、問題領域の全体に、広く、薄く分散させるのは、失敗パターン。 ほんとうに役に立つソフトウェアを造るために、「問題の核心」を正しく捕らえ、そこに集中して、設計・実装し、リファクタリングして、洗練させていくこと。 Core Domain の特定と、設計・実装が、プロジェクト全体の成果を大きく左右する。 ・Core Domain とは何か? ・どうやって発見するか? ・どうやって表現するか? ・Core 以外の扱い方は? ... これが、 Domain-Driven Design(DDD) 15章 "Distillation"(抽出
実践DDD [Domain-Driven Design] 第1回:DDDを俯瞰する 印刷 株式会社豆蔵 BS事業部 笠原 規男 2008/11/17 [アーキテクチャ] DDDとは DDDは、Domain-Driven Designの略で、ドメイン駆動設計と訳されます。エリック・エヴァンス氏が、著書『Domain-Driven Design』(以降DDD本)で提唱している開発方法論です。同書のサブタイトルには「Tackling Complexity in the Heart of Software」(ソフトウェアの核心にある複雑さに立ち向かう)とあります。複雑化するシステムにおいて、いかにユーザのニーズを把握、実現し、保守・拡張していけば良いかの戦略を示したものです。 同書は、一部のエンジニアには、マーチン・ファウラー氏の『エンタープライズアプリケーションアーキテクチャパターン』(以降P
ドメイン・モデルと開発に注力しないと"太ったサービス・レイヤ"と"ドメイン・モデル貧血症"によるアプリケーション・アーキテクチャになってしまいます。この場合、ファサード・クラス(通常はステートレス・セッション・ビーン)にどんどんビジネス・ロジックが溜まっていき、ドメイン・オブジェクトがgetter/setterからなる単なるデータの運び屋のようになってしまいます。このアプローチをとるとドメイン固有のビジネス・ロジックやルールが複数の異なるファサード・クラスに散在(時には重複)することになります。 "ドメイン・モデル貧血症"はたいていの場合、コストに見合いません。他の企業と比較して利点があるわけではなく、このアーキテクチャの下でビジネス要求の変化を実装するには開発と本番環境へのデプロイするのに時間がかかり過ぎます。 DDD実装プロジェクトにおけるいろいろなアーキテクチャや設計について見ていく
In this article, we’ll go through the reasons to (and not to) employ the domain model pattern, the benefits it brings, as well as provide some practical tips on keeping the overall solution as simple as possible. Contents What Is It? Reasons Not to Use the Domain Model Technology Reasons to Use the Domain Model Scenarios for Not Using the Domain Model Scenarios for Using the Domain Model More Comp
Windowsパソコンで組んだLAN上でファイルやプリンターなどを共有する際は通常、「ワークグループ」か「ドメイン」の設定をします。両者は基本的に共有パソコン(サーバー)やユーザーの管理の仕方などに違いがあり、LANの規模などによって使い分けます。 まずワークグループとは、LAN上でファイル共有などをする場合に、他のパソコンを参照しやすいように設定するグループです。設定は簡単。例えばLAN端子を搭載しているWindows Meパソコンなら「マイ ネットワーク」を右クリックして「プロパティ」を開きます。そこで「識別情報」タブの画面にワークグループの名前を入力するだけです。LAN上の各パソコンに同じワークグループ名を設定しておけば「マイ ネットワーク」などで、それらのパソコンが同じグループとして表示されます。 ただしワークグループで共有ファイルに誰がアクセスできるかを管理するには、共有設定をし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く