domaindrivendesign @ ウィキ
domaindrivendesign @ ウィキ

DDD Quickly

DDD Quicklyの議論ネタを書き溜める場所。

はじめに：なぜドメイン駆動設計なのか

  • 「アーキテクトの集まり」はInfoQでしょうか。Gregor HohpeやRod Johnsonも賛同してるのが意外というか。 -- 渡邉 (2009-07-23 15:17:08)
  • Gregor氏はどちらかというとインフラ（ランタイム）に回帰しているようなことを言っていたし。[http://hibituredure.blogspot.com/2009/04/blog-post.html] -- 渡邉 (2009-07-23 15:20:39)
  • ただし、ランタイムを「使う」側からすると、ますますインフラの重要度が低下しているとも言える。 -- 渡邉 (2009-07-23 15:21:46)
  • ソフトウェア進化の方向はいろいろあるけど、複雑なソフトウェアに取り組むためのドメイン設計というのは、間違いなくその中の大きな流れのひとつだと思う。 -- 渡邉 (2009-07-23 15:22:59)
  • ソフトウェア進化の方向性の概観を得るには、萩原さんの「アーキテクトの審美眼」がおすすめ。 -- 渡邉 (2009-07-23 15:23:34)
  • 少なくともJava界隈では、インフラはすでにDoesn't matterになってきているんじゃないかな、と思っている。最近大きなトレンドってないよね。 -- 渡邉 (2009-07-23 15:24:35)
名前:
コメント:

イントロダクション

  • 「ソフトウェアの設計は芸術です」は訳しすぎじゃないかなぁ。「技芸です」くらいがいいと思う。 -- 渡邉 (2009-07-23 15:28:54)
  • ちなみに、原文は"Software design is an art, and..." -- 渡邉 (2009-07-23 15:29:16)
  • 厳密な科学や定理と、ソフトウェア設計との関係を書いた部分はほぼ同感。「ソフトウェア作成過程全体に適用できるような、原則や技法（discover principles and techniques useful to be applied throughout the process of software creation）」はSupple Designで出てくるやつだと思う。 -- 渡邉 (2009-07-23 15:31:22)
  • Yahoo Groupsのフォーラムはすさまじい投稿数なので圧倒注意。誰か定期的に興味深いネタ拾ってこれれば面白い。 -- 渡邉 (2009-07-23 15:32:18)
名前:
コメント:

ドメイン駆動設計とは何か

  • P3.ただ座ってコーディングしているだけでは複雑なソフトウェアは作れない。 -- 渡邉 (2009-07-23 15:40:43)
  • 「ドメインに円滑に適合するソフトウェアを作るためのもっとも良い方法は、ドメインの反映としてのソフトウェアを作ること」この命題が真と考えるかどうかが大きな分かれ道になりそう。 -- 渡邉 (2009-07-23 15:43:04)
  • 「ドメインに深く根をおろしていないソフトウェアは、時間が経ってドメインが変化しても対応できない」対応できなければ余分にお金をもらえるような場所では魅力的じゃないんだろうな。 -- 渡邉 (2009-07-23 15:44:44)
  • ドメインをソフトウェアに反映するには、ドメインの抽象が必要。イコール、ドメインのモデルが必要。モデルは、特定のダイヤグラムではなく、概念。 -- 渡邉 (2009-07-23 15:46:17)
  • 抽象を作る際に、何を取り込み何を捨てるかを決めていく。これが設計作業。 -- 渡邉 (2009-07-23 15:46:59)
  • モデルは頭の中だけにあります。<= JavaEE勉強会ではこれがわかる？までに大議論があった。 -- 渡邉 (2009-07-23 15:48:00)
  • BDUを避け、アジャイルを好む。これもDDDの特徴。参考 -- 渡邉 (2009-07-23 15:50:14)
  • モデルは、頭の中にある概念で、表現方法としては、ダイヤグラム・コードがある。言語としてユビキタス言語を使う。認識あってる？ -- 渡邉 (2009-07-23 16:29:40)
  • あ、文書もあった。 -- 渡邉 (2009-07-23 16:32:07)
  • ドメインをモデル化するときに、Asisをモデル化するのか、Tobeをモデル化するのか？それともリファクタリングによって良くしていくのか？ -- 狩野 (2009-07-29 14:28:19)
  • 「最大の問題はアナリストから業務の専門家へ、または開発者からアナリストへのフィードバックがないことです」スパイラルをまわせということ？ -- 狩野 (2009-07-29 14:33:04)
名前:
コメント:

ドメインの知識を構築する

  • 「ひょっとしたら管制官の見方とは大きく異なっているのかもしれませんが、こういう抽象的な見方は不可欠であり、後になって役に立ちます」これは結構重要だと思う。 -- 渡邉 (2009-07-23 15:53:24)
  • 大きな問題は、ドメインエキスパートが対話についてこれるかどうか、ということと、そもそもドメインエキスパートとアクセスできるかどうか、ということだろうか。 -- 渡邉 (2009-07-23 15:55:57)
  • このあたりは、インハウスで開発していた経験がある人は結構違和感ない、と話してました。面白い。 -- 渡邉 (2009-08-10 10:59:41)
名前:
コメント:

ユビキタス言語

共通言語の必要性

  • ドメイン駆動設計の核となる原則は、ドメインモデルに基づく言語を使うこと。開発者の言語でも、ドメインエキスパートの用語でもない。 -- 渡邉 (2009-07-23 15:59:40)
  • しかし、結局、ユビキタス言語にはドメインエキスパートの言語がかなり多く入ってくると思う。開発者の言語は少なそうだけど。 -- 渡邉 (2009-07-23 16:00:22)
  • この図がわかりやすいと思ったのでのせてみた。 -- 渡邉 (2009-07-23 16:27:59)
  • 真ん中のかさなってるところがユビキタス言語です。 -- 渡邉 (2009-08-04 11:35:35)
  • 用語辞書とかそういうものを指す？という話がありました。おそらくですが、用語辞書はユビキタス言語を表現する一形態ではあると思います。が、それ以外の形態をとることもあるはずです。たとえば、日常会話であるとか、コードであるとか、ダイヤグラムの要素であるとか、そういうもの。 -- 渡邉 (2009-08-04 11:36:59)
名前:
コメント:

ユビキタス言語を構築する

  • 目次とタイトル間違ってる。誤植はっけーん。 -- 渡邉 (2009-07-23 16:33:04)
  • 相変わらず対話がうそ臭い。だいたいは、開発者がなんかわかった風な発言をしたあたりがうそ臭い。ドメインエキスパート賛同してないだろ、みたいな。 -- 渡邉 (2009-07-23 16:30:48)
  • ここでもモデルの表現の話が出てきてる。モデルの表現方法は、「文書」「ダイヤグラム」「コード」。このバランスは、プロジェクトの性質が決める。 -- 渡邉 (2009-07-23 16:34:04)
  • モデルはモデルそのものであって、文書やダイヤグラムやコードではない（ホント？）、という話をしていた際には、かなり混乱があった気がする。 -- 渡邉 (2009-08-04 11:39:16)
  • モデルは頭の中にあるものだ、という言い方をしたのがまずかったのかもしれない。頭の中にしかないって、それじゃみんなわからなじゃん、みたいな話が出てきたが、表現形態としてはいろいろあってOKだと思います。 -- 渡邉 (2009-08-04 11:40:19)
名前:
コメント:

モデル駆動設計

  • 「推奨できる設計手法のひとつに」は誤訳気味？原文は”One of the recommended design techniques is the so called analysis model, which...”なので、「（一般に）推奨されている設計手法」だと思うんだけど。 -- 渡邉 (2009-07-23 16:39:02)
  • そして、そのすぐ下で軽く分析モデルDisってるし。 -- 渡邉 (2009-07-23 16:39:25)
  • 分析モデルアプローチでは、モデルに従ったソフトウェアができるとは限らない、というかできないのが問題。 -- 渡邉 (2009-07-23 16:41:07)
  • モデルの表現が「文書」「ダイヤグラム」「コード」であることを考えると、これらが乖離していることは許容しがたいんだろう。 -- 渡邉 (2009-07-23 16:41:45)
  • 分析と設計の間に致命的な乖離が生まれるのは、作業を通じて各自が得た知見をチームの他のメンバに伝えていないから。 -- 渡邉 (2009-07-23 16:43:20)
  • 手続き型で実装すると、データの意味が開発者にしかわからない。コードそのものが意味をはっきりと表現しないから。 -- 渡邉 (2009-07-23 16:45:21)
  • モデル駆動設計で手続き型（関数型もか）を使える場面は限られている、ということか。まぁたぶんそうだろうな。で、インフラの都合上から関数型パラダイムを選ぶ場合には、モデル駆動設計を捨てることになるってことか。 -- 渡邉 (2009-07-23 16:46:25)
  • ここで言うモデルは顧客のビジネスのうちシステム化対象のものを指しているように思うけど、それ以上の範囲を含むいわゆるビジネスモデリングは含まない？含まなくて良い？ -- 村井 (2009-07-25 06:41:11)
  • 欧米では丸投げせずにシステム化対象範囲をMBA取得者とかが戦略的に決定しているから、日本みたいなステークホルダ調整みたいなことはしなくていいってこと？ -- 村井 (2009-07-25 06:41:28)
  • 全体的な話ですが、アナリストとか開発者とかのロール的なものや、プロセス的なものは特になし？ -- 村井 (2009-07-25 07:07:43)
  • 「分析モデルはソフトウェアとして実装することを考慮していない。」「モデルを作成するときはソフトウェアとその設計を考慮すべきです」ここがわからない。分析モデルとソフトウェア設計を考慮するモデルの関係は？ -- 狩野 (2009-07-29 14:44:21)
  • ビジネスモデリングは含んでいないように思えたけど、もう一度本書を読まないとなんともいえないですね。という話になった。 -- 渡邉 (2009-08-04 11:41:30)
  • プロセス系の扱いについては本書に書いてあって、確かDDDの本ではあまり取り上げない、となっていたはず。ただし、迅速なフィードバックが必要なので何かしらの繰り返し型アプローチが必要だと思う。 -- 渡邉 (2009-08-04 11:42:42)
  • ロール的なものについては、ドメインエキスパート、開発者、モデラーくらいが代表的な登場人物で、あとはちょくちょくマネージャとか出てくるくらいだったと思います。アーキテクチャチームとかも少しだけでてきたかな。 -- 渡邉 (2009-08-04 11:43:42)
  • 分析モデルは、ソフトウェア設計を考慮していないので、ソフトウェア設計を考慮したモデルではない、という関係だと思います。＞狩野さん -- 渡邉 (2009-08-04 11:44:38)
  • このあたりで、実際のシステムを例に取るとモデルってのはどんな風になるのかについて、わりと時間をとって議論。みんなのなじみのシステムを例にとって色々話しあった。システムの類型化や、どのあたりにDDDを適用できそうか、などなど。 -- 渡邉 (2009-08-04 11:47:24)
名前:
コメント:

モデル駆動設計の基本要素

名前:
コメント:

レイヤアーキテクチャ

  • あれ？InfrastructureからDomainへの依存関係ないんだっけ？ -- 渡邉 (2009-07-23 16:49:04)
  • 書いてないだけかなぁ。説明の文章見ても、UIやドメインオブジェクトに依存すると思うんだけどなぁ。呼び出し順序という意味だと確かにこうなんだけど。この矢印は依存関係ではないのか。 -- 渡邉 (2009-07-23 16:50:46)
  • http://dddsample.sourceforge.net/architecture.html -- 村井 (2009-07-25 06:30:43)
  • イメージ的には↑の図のように、各層にInfraが居るのですよね。Infraは要はフレームワーク類かと。なので↑だと矢印逆なのでややこしいですが、Quicklyの矢印の向きでいいのでは？ -- 村井 (2009-07-25 06:36:06)
  • 例えば UI層のInfraはテンプレートエンジンとか、Domain層のInfraはORMとかかなと思ったので。 -- 村井 (2009-07-25 06:36:30)
  • EJBやPoEAAの Integration層とかData Source層は無いのですね。Domain LayerのInfrastructureにあたるのかな -- 村井 (2009-07-25 06:53:55)
  • DDD:Application Layer = PoEAA:Service Layer ？ tx境界だとか thin facadeなところとか。 -- 村井 (2009-07-25 06:55:40)
  • PoEAAとか他のLayer定義とのマッピングは整理したいですね。２分で挫折しましたが。 -- 村井 (2009-07-25 06:57:20)
  • ビジネスオブジェクトってなんでしょうか？ビジネスロジックを持っているオブジェクト？ -- 狩野 (2009-07-29 14:48:15)
  • アプリケーションレイア　= MVCのControllerという認識でよい？ -- 狩野 (2009-07-29 14:50:55)
  • 矢印の向きの話：Domain<-Infraでやっぱり良いのかも。後で引用したCargoRepositoryとCargoRepositoryHibernateがまさにそうでした。(前者がDomain,後者がInfraと書いてるし) -- 村井 (2009-08-06 13:15:07)
  • Framework観点で、(Domainを含まない)FW部分と、それを利用する部分がLayerの境目だと思っていましたが。Domain観点で、Domainか、そうでないものを含むか、で分けるんですね当たり前ですが。 -- 村井 (2009-08-06 13:16:42)
  • とはいってもDomainからInfraを利用するところは依存があるのかとおもったのだけど、DIで解決すればよし？ -- 村井 (2009-08-06 13:17:22)
  • 「ビジネスルールを変更するために、UIコードや～変更箇所を探す必要があるかもしれません」依存していれば当たり前と考えてしまったが。 -- 狩野 (2009-08-10 04:44:57)
  • ↑まあ(密着:coherent)の程度の話か。 -- 狩野 (2009-08-10 04:49:00)
  • (狩野さんともかぶりますが、)アプリケーションレイヤは何を指し示すのでしょう？Controller？ -- 崎山 (2009-08-10 18:24:20)
名前:
コメント:

エンティティ

  • すみません。早くもつまづいてしまいました。 -- 福久 (2009-07-29 09:19:51)
  • 二人以上のユーザが同一エンティティを見たいとしたら、どうなるのでしょうか？ -- 福久 (2009-07-29 09:20:54)
  • 例えば、あるユーザが口座エンティティを作りました。そのインスタンスができました。 -- 福久 (2009-07-29 09:21:59)
  • その後すぐ、別のユーザが同じ口座エンティティを参照したいとしたらどうなるのでしょうか？まったく同じインスタンスを参照させる？もう参照は無理？ -- 福久 (2009-07-29 09:24:01)
  • オブジェクトを識別できる方法を定義することがポイント。その識別方法で常にオブジェクトが特定できること -- 狩野 (2009-07-29 15:10:27)
  • >福久さん ↑まったく同じインスタンスを参照させるのでは？（参照できるかできないかは別の話で）。アイデンティティが同じものは同一のものとして扱う必要があるから。 -- 狩野 (2009-08-10 16:01:18)
  • Railsno -- 狩野 (2009-08-10 16:09:34)
  • Railsのidとか？ -- 狩野 (2009-08-10 16:09:55)
名前:
コメント:

バリューオブジェクト

  • バリューオブジェクトはimmutableにすべき -- 狩野 (2009-07-29 15:14:50)
  • 不変であり一意性をもたないバリューオブジェクトは共有できます　－Flyweight パターン？ -- 狩野 (2009-07-29 15:17:11)
  • ↑バリューオブジェクトは「共有可能ならば」immutableにすること -- 狩野 (2009-07-29 15:18:13)
名前:
コメント:

サービス

  • サービスが内部状態を保持しないかどうかは、現在では微妙になっているらしい。ソースは佐藤さん。 -- 渡邉 (2009-07-23 16:53:17)
  • Domain Application Infra どこにでも在り得る。のは状態を持たないFacade的なやつをサービスと呼ぶことにしたからかと思ったのですが、↑なんですねぇ -- 村井 (2009-07-25 06:46:00)
  • どのオブジェクトにも属さない振る舞い/複数のオブジェクトを横断して作用する振る舞いはサービスとして定義する -- 狩野 (2009-07-29 15:21:34)
  • サービスとはサービスとしてふるまうオブジェクトのことではありません？？？わかりません -- 狩野 (2009-07-29 15:24:27)
  • 1.サービスとして作成される操作はドメインの概念をあらわしているが、EntityやValueObjectに含めると違和感がある。　違和感(naturally belongs to)ってなに？ -- 狩野 (2009-08-10 16:42:10)
  • サービスのパラメータ、結果（戻り値）はdomainObjectsであるべき(DDD：p.105)・・・当たり前だけど -- 狩野 (2009-08-26 08:28:58)
  • 2.はDDD:p.105だと「サービスのinterfaceはdomainModelの別の要素とひも付けて(in terms of)定義されるとあるが。DDD quicklyと同じことを言っているのか、または別のことを言っているのか？ -- 狩野 (2009-08-26 08:40:19)
名前:
コメント:

モジュール

  • BoundedContextとの関係がいまいちわからない。あわさった例がほしい。 -- 渡邉 (2009-07-23 16:55:50)
  • 確かに。粒度もピンとこない。 -- 村井 (2009-07-25 06:47:27)
名前:
コメント:

アグリゲート

  • Quickly だけだと Aggregate の本質はわからず、Purchase のサンプルでもイマイチ「rootとboundaryを明確にする」がポイントだが、クライアントあっての概念。Aggregate と永続的トランザクションの単位をあわせるといいという話？ -- sinozaki (2009-07-19 13:55:02)
  • オブジェクトの一貫性保持と考えた方がいいんじゃない気が。永続化の一貫性は、Aggregateをまたがる一貫性も扱うと思いますし。 -- 渡邉 (2009-07-23 16:59:43)
  • しかし、いまいちわかった感がないのも事実。 -- 渡邉 (2009-07-23 17:00:05)
  • 本書の例を見てそこで議論するのがいいかもしれないです。 -- 渡邉 (2009-07-23 17:00:34)
  • 本書の方で、まずい状況を確認してからこのパターンを見ると、わりとわかりやすい気もした。 -- 渡邉 (2009-07-25 16:59:05)
  • オブジェクト同士の関連を、1つのオブジェクトとオブジェクトのコレクションの1対1の関係に変更すると吉 -- 狩野 (2009-07-29 15:27:40)
  • アグリゲートは1つのルートを持つ。ルートはエンティティ。アグリゲート外部からは、ルート経由でしかオブジェクトにアクセスできない -- 狩野 (2009-07-29 15:29:30)
  • カプセル化の話？ -- 狩野 (2009-07-29 15:30:11)
名前:
コメント:

ファクトリ

  • オブジェクトの生成過程を分割不可能にすることが重要です。Atomic重要 -- 狩野 (2009-07-29 15:32:26)
名前:
コメント:

リポジトリ

  • CORBA の Naming Servie とほぼ同じ印象。Aggregate ともに考えると両者のイメージがより具体化しそう。クライアント側から渡す識別子は特に説明がないが、文字列だけでよい? -- sinozaki (2009-07-19 14:07:07)
  • 「取得条件を仕様として定義することです」じゃわからんだろう…ここでいう「仕様」とは、「Specification」というパターンです。see alsoSpecification -- 渡邉 (2009-07-23 17:06:32)
  • DAOと何が違うの？という話が出ました。コンテキストが違うだけで、メカニズムは同じだろ、という結論だった気が。 -- 渡邉 (2009-07-23 17:08:03)
  • リポジトリという名前から、確かにNamingService的なものかと最初思いましたが、読むとDAOっぽいですね。DDD Sampleチラ見しても、CargoRepositoryとCargoRepositoryHibernateが居るし。 -- 村井 (2009-07-25 06:52:01)
  • http://dddsample.sourceforge.net/characterization.html#Repositories -- 村井 (2009-07-25 06:52:18)
  • 参考: CORBA NamingServiceてのは、JavaでいうJNDIみたいなもん。 -- 村井 (2009-07-25 06:52:36)
  • 「Specification」...条件の階層化かしら。。。 -- sinozaki (2009-07-29 13:07:06)
  • 分散アクセスのためのパターンは理解できていない・・・参考文献希望（日本語が望ましい） -- 狩野 (2009-07-29 15:39:17)
  • proxyパターン的なもの？ -- 狩野 (2009-07-29 15:44:47)
  • 「リポジトリへ直接アクセスする必要があるのはアグリゲートのルートだけになるように設計しましょう」なぜ？理由がわからなかった。 -- 狩野 (2009-07-29 15:47:38)
  • たぶん誤訳。"Provide repositories only for Aggregate roots that actually need direct access." -- 渡邉 (2009-07-29 17:49:17)
  • 実際に直接アクセスが必要になるアグリゲートルートのためだけにリポジトリを作りましょう。 -- 渡邉 (2009-07-29 17:50:11)
名前:
コメント:

リファクタリングのためのさらに深い洞察

継続的なリファクタリング

  • ドメインとモデルに対するリファクタリング、というなじみのない？コンセプトが登場。 -- 渡邉 (2009-07-23 17:11:21)
名前:
コメント:

鍵となる概念を明らかにする

  • もし Bookshelf に get() とあれば Service or Repository ?(Fat object かな?) -- sinozaki (2009-07-19 14:34:00)
  • このあたりが一番面白いんじゃないかなぁ。 -- 渡邉 (2009-07-23 17:12:56)
  • しかしこの例はわかりづらいな…これも本書の例の方がいいと思う。 -- 渡邉 (2009-07-23 18:33:05)
名前:
コメント:

モデルの完全性を維持する

  • ここから、Strategic Design。 -- 渡邉 (2009-07-23 18:33:33)
  • てか、今ここを資料にまとめているけど終わってなくて泣きそう…。 -- 渡邉 (2009-07-23 18:34:11)
  • どっかの Agile 本で出てきそうな内容 -- sinozaki (2009-07-29 13:20:14)
名前:
コメント:

コンテキスト境界

  • この訳いいのか？？元は”BOUNDED CONTEXT”。境界じゃなくて、コンテキストのことなんだけど… -- 渡邉 (2009-07-23 17:10:07)
  • モジュールとの関係がちゃんと（？）書いてあった。 -- 渡邉 (2009-07-23 18:35:58)
  • コンテキストごとにそのコンテキストのモデルを持つ。 -- 狩野 (2009-08-05 19:24:54)
名前:
コメント:

継続的な統合

  • 概念のContinuous Integrationが、日々の会話、というのは面白い見方じゃないだろうか。 -- 渡邉 (2009-07-23 18:36:50)
名前:
コメント:

コンテキストマップ

  • 訳は「マップ」になってるけど、Mapって「写像」と「地図」どっちなんだろ？訳者も迷ったからカタカナにしたのかな？ -- 渡邉 (2009-07-23 18:37:47)
  • 本書を読んだ感じだと地図っぽいなーと思ったので、今まで地図で訳してた。 -- 渡邉 (2009-07-23 18:38:27)
名前:
コメント:

共有カーネル

名前:
コメント:

カスタマ-サプライヤ

名前:
コメント:

順応者

名前:
コメント:

防腐レイヤ

  • 「基本的なデータはドメインモデルについての情報を含んでいません」DBの制約みたいなはなし？ -- 狩野 (2009-07-29 15:51:21)
名前:
コメント:

別々の道

  • このパターンの採用を非常によく見かける。 -- 渡邉 (2009-07-23 18:40:40)
名前:
コメント:

公開ホストサービス

名前:
コメント:

蒸留

  • 思い切ってはしょられてるなぁ。実際は、コンテキスト境界～公開ホストサービスと同じくらいの数のパターンがあるんだけど。 -- 渡邉 (2009-07-23 18:41:45)
  • コアドメイン(特化したもの)と サブドメイン(一般的な概念) を分けるというのは面白い。前者が重要で自前でというのは確かに。後者の既製品って？例えば地図に位置表示とかをGoogle Mapつかっちゃおうみたいなこと？ -- 村井 (2009-07-25 07:05:44)
  • うまい例が思いつかなかった・・・ -- 村井 (2009-07-25 07:06:09)
名前:
コメント:

今日におけるDDDの諸問題：Eric Evansへのインタビュー

  • 自分自身の最も優れた能力を、ドメインを理解することに費やし…ねばならない。 -- 渡邉 (2009-07-23 18:43:18)
  • すべてにDDDを適用しようとしないでください。 -- 渡邉 (2009-07-23 18:46:06)
  • 適用箇所にコンテキストマップを使うことを推奨してたんだなぁ。 -- 渡邉 (2009-07-23 18:46:21)
  • Quickly 読んで思ったのは、『「Transaction Script」よりいいよ』っていうの説明がなかった。Evansたんのなかではあくまでドメインはドメインという意味合いかな。 -- sinozaki (2009-07-29 13:12:14)
  • 「業務ドメインに注力する」の対極(?)として、フレームワークに業務を合わせるというアプローチもありますよね。どのへんが切り分けるポイント？ -- 狩野 (2009-07-29 15:54:24)
名前:
コメント:

タグ：

+ タグ編集
  • タグ：
タグの更新に失敗しました
エラーが発生しました。ページを更新してください。
ページを更新
「DDD Quickly」をウィキ内検索
最終更新：2009年08月26日 08:40
ツールボックス

下から選んでください:

新しいページを作成する
ヘルプ / FAQ もご覧ください。
添付ファイル