domaindrivendesign @ ウィキ
domaindrivendesign @ ウィキ

AModelExpressedinSoftware

Chapter 5 : A Model Expressed in Software

  • P81:最後の段落の個所。訳しても何を言っているのか本意がとれない。 -- sinozaki (2009-10-14 22:47:02)
  • ENTITIESとVALUE OBJECTSの違いを問いかける形式で記述してるんだと思います。 -- kentaro714 (2009-10-21 17:42:55)
  • オブジェクトは持続性と一意性を持ちますか？つまり、異なる状態や異なる実装にまたがって追跡されますか？それとも単に、ほかの何かの状態を表す属性にすぎませんか？これが、ENTITIESとVALUE OBJECTSの基本的な違いです。 -- kentaro714 (2009-10-21 17:46:24)
名前:
コメント:

Associations

  • P83:1.縦断的な命題を負わせる。2.制約を与え、効果的に多様性を減らす。3.本質的でない関連を除去する。「traversal direction」ってどう訳すとわかりやすい？ -- sinozaki (2009-10-15 01:11:52)
  • 予断ですが、モデル化の際にここの話のように、両/片方向や関連端を細かく明記しますか?私はあまりモデル上では表現しないほうです。 -- sinozaki (2009-10-15 01:36:26)
  • 自分なら、1は「関連の向きを強制する」とかかなぁ…。もっとやわらかく、「なるべく1方向関連を使う」とかにしちゃってもいいのかも。 -- kentaro714 (2009-10-21 17:59:12)
  • 自分はわりかし書く方ですね。特にやばそうなとこや、ややこしそうなとこを優先的に書く感じでしょうか。 -- kentaro714 (2009-10-21 17:59:59)
  • 依存の向きは絶対書く派です。多重度も自明なもの以外は必ず書きます。これが設計だと思ってるんで。我流モデリングだけど -- 村井 (2009-11-04 13:06:50)
  • なので、この章は楽しい。ちなみに qualifier(限定子)は最近好きなんです -- 村井 (2009-11-04 13:08:58)
  • P84:Figure5.1はなにをいいたいのか解説希望 -- 狩野 (2009-11-04 17:04:35)
  • P84:どういう意味?→it also gives significance to the remaining bidirectional associations. -- 狩野 (2009-11-04 17:13:52)
  • @狩野 わかりづらいすね、これ。次の文と一緒に読むとわかりやすいかも。「～だけでなく、それでも双方向のまま残った関連が重要である、ということも教えてくれます。」みたいな感じ？ -- kentaro714 (2009-11-04 17:56:34)
名前:
コメント:

ENTITIES (A.K.A. Reference Objects)

  • P91:continuity threading = 一貫性？thread がいろいろ出てくるがどう訳すとよいか -- sinozaki (2009-10-19 22:48:58)
  • P91:On the other hand,... の個所を確認させてもらえるとありがたいです。 -- sinozaki (2009-10-20 01:36:54)
  • P91にも a thread of とかありますが、訳さなくていいんじゃないかなぁ… "a thread of continuity and identity" 概念訳なら「継続性と一意性」とかでどうだろう。 -- kentaro714 (2009-10-21 18:25:01)
  • P90: Does the user ... care if I am the same person I was at age five ? = 何に対して一意か、はシステムによるってことですね。自分の捉え方はPKを決める作業ｗ -- 村井 (2009-11-18 12:13:26)
名前:
コメント:

Modeling ENTITIES

  • 言っている事は理解できるのだが、このモヤモヤとした感覚はなんだろう。ENTITIES->一意性があるものとなっているが、一意性があるから->ENTITIESと判断してはいけないような気がする-- sinozaki (2009-10-20 02:20:47)
  • @shinozaki Entitiesの定義は単に「一意性があるもの」とするとわかりづらい気が。ValueObjectsの定義が「"概念的に"一意性がないもの」なので、Entitiesも「"概念的に"一意性があるもの」なんじゃないでしょうか。単なる一意性はValueObjectsにもありますよね（属性値が同じものは一意）。概念的な一意性というのは、値ではなくそのもので識別すること、ほぼ「ライフサイクルを通じた一意性を持つ」と同義なんじゃないかなーと思っているのですが。 -- kentaro714 (2009-11-04 15:02:27)
  • [Memo]P93: 後から読み返してみると、重要なことが書いてあった。Entitiesが持つ属性や振る舞いは、定義上もっとも本来的な特徴だけにとどめておくべきで、それ以外の特徴は他のEntityやValueObjectに追い出すべき。本来的な特徴のための機能とは、インスタンスの識別、検索、一致に関する諸機能。 -- kentaro714 (2009-11-04 15:05:27)
  • 2個上言い過ぎたかも。IDは結果であって、ライフサイクルを通じて、値以外で一意性を識別できる必要がある、くらいかも。その場合、たいていはIDを使うことになるとは思いますが。 -- kentaro714 (2009-11-04 16:34:59)
  • [Memo] P94: ex, if a Customer has many contact phone numbers ... (it) should stay with the Sales Contact. = 自分の捉え方は正規化 -- 村井 (2009-11-18 12:15:43)
名前:
コメント:

Designing the Identity Operation

  • 可変な属性値を持っており、それらの値が変わったにもかかわらず一意性を確保する必要があるために、識別用な特別な不変属性を定義したものがEntity、と言ってもいいのか。 -- kentaro714 (2009-11-04 16:41:07)
  • [Memo]P95: IDは一度生成されてしまえば、ユーザーが関知する必要はない。 -- kentaro714 (2009-11-04 16:43:06)
  • [Memo]P96:が、最終的には必要とされるケースもある（どっちだよ） -- kentaro714 (2009-11-04 16:45:40)
  • [Memo]P96: 電話番号のように、すでに存在している識別子がそのまま使えそうに思えることもあるが、それらは今回の目的とは関係なく変わる可能性がある。よって、特別な識別子を払い出すことが多い。電話番号なら、電信会社なら識別子に使えるかもしれないが、他のビジネスで顧客の識別子として電話番号を使うとマズいケースが多いのは当たり前。 -- kentaro714 (2009-11-04 16:48:45)
  • P95:Defining identity demands understanding of the domain:ドメインの理解がidentityを定義する前提として求められる -- 狩野 (2009-11-30 16:47:36)
  • P95:the means of identification demand a careful study of the domain:ここでもdomainの把握が重要ということが述べられている。（大事なことなのでry -- 狩野 (2009-11-30 16:57:12)
名前:
コメント:

VALUE OBJECTS

  • P98:「VALUE OBJECTS can even reference ENTITIES.」ENTITIESからVALUE OBJECTSを探ってもよいということ。 -- sinozaki (2009-10-21 01:39:51)
  • [Memo]P98: WhichやWhoでなく、Whatのみを気にすればよいもの。 -- kentaro714 (2009-11-04 17:08:48)
  • Whatのみを気にすればよい、という特徴と不変性との関係は？別に可変にもできると思うけど。基本的に不変であるほうが望ましい、という設計原則に沿った結果、ValueObjectはそれが可能なので不変にしてる、ってこと？ -- kentaro714 (2009-11-04 17:11:48)
  • 設計に不要な複雑性を持ち込ませたくない、というフォースが大きいのか。設計テクニックとみなしてOK？ -- kentaro714 (2009-11-04 17:15:48)
  • @kentaro714 不変性との関連は、P101の最下段に全部書いてありました。 -- kentaro714 (2009-11-04 17:42:46)
  • Fig. 5.6の conceptually wholeとはどういう意味なのでしょうか？意味的なかたまりごとにわけてvalue objectをつくるということでしょうか？ -- tiquer (2009-11-14 23:02:51)
  • @tiquer 意味的なかたまりごと ... 自分の見解もそうです。Addressなら street,city,stateの塊が概念的にwholeだということかと。 -- 村井 (2009-11-18 12:18:41)
  • P98: VALUE OBJECTS can even reference ENTITIES. = PoEAAのVALUE OBJECTでは触れられてない点かな。そのValueが同じかどうかは参照する Entitiyが同一かも見るということに？ -- 村井 (2009-11-18 12:20:51)
  • P98:左部のValueObjectとEntityの例がいまいち頭に入ってこない＞＜　解説希望 -- 狩野 (2009-11-30 20:34:08)
名前:
コメント:

Designing VALUE OBJECTS

  • P100:VALUE OBJECTS のインスタンスは、これを参照している Entitity が普遍である限り(Identify が変わらない)同じインスタンス(FLYWEIGHTなどによりインスタンス生成を制御)を使ってもよい -- sinozaki (2009-10-21 12:28:16)
  • P100: なんだか非常に深遠な話である気がするんだけど、値の同一性ではEntityの同一性が判断できない理由は、Entityが実は別にプロパティを持っているから？これは、情報的なプロパティに限らないんだけど。 -- kentaro714 (2009-11-04 17:19:58)
  • [Memo] Immutableがお勧めだけど、性能面でsharedの方が優位な場合がある。 確か、Eclipse/SWTのPointクラスはSharedなパターンだったと思う。 http://help.eclipse.org/galileo/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/swt/graphics/Point.html -- 村井 (2009-11-18 12:26:47)
  • ↑失礼 Shared(w/ Immutable) ではなくて、Mutableの間違いですね -- 村井 (2009-11-19 09:56:59)
  • あきらかにobject生成コストを意識したMutableの例はコチラでした。SINGLETONまでAPIで用意したPointクラス。http://help.eclipse.org/galileo/topic/org.eclipse.draw2d.doc.isv/reference/api/org/eclipse/draw2d/geometry/Point.html#SINGLETON -- 村井 (2009-11-20 16:12:36)
名前:
コメント:

Designing Associations That Involve VALUE OBJECTS

  • bidirectionalの辺何言ってるかよくわからん。 -- kentaro714 (2009-11-04 17:49:07)
  • 唯一わかったのは、「双方向関連のValueObjectはやめれ」 値なのだから、その２つはWhole化すべきだったり、単方向で済む情報を外に出したり、ということをしなさいということなんだろうか -- 村井 (2009-11-18 12:30:45)
  • P102:entity間の双方向の関連は維持が難しいだけかもしれないが、2つのvalueObjectの双方向の関連は意味がない。 -- 狩野 (2009-11-30 21:14:38)
名前:
コメント:

SERVICES

  • P104:"doers"擬人化されたオブジェクトですかねぇ -- sinozaki (2009-11-16 23:29:46)
  • P105:SERVICESは名詞よりも動詞として名づけられる。ユビキダス言語上で認識される動詞がSERVICESなのか？ -- sinozaki (2009-11-16 23:40:15)
  • P105:３つの特性・ENTITY/VO中では不自然なoperationであるのに、モデル間の要素として定義できるものって1と２は逆のことを言っているような... -- sinozaki (2009-11-16 23:54:47)
  • 結局SpecificationもSERVICEのサブセットと見えてしまった。 -- sinozaki (2009-11-17 00:06:30)
  • @sinozaki P105: #2は、other elements of とかあるので、自分の中では、１つのEntity/ValueObjectに閉じることのできないもの、と捉えてます -- 村井 (2009-11-18 12:47:29)
名前:
コメント:

SERVICES and the Isolated Domain Layer

  • P106:この例でメール送信SERVICEを呼んでいるのは誰？アプリケーション層が呼んでいるインフラ層のSERVICEでいいんだろうな。であればアプリケーション層自体は手続き的とみてもよい事だろうか？ -- sinozaki (2009-11-17 00:14:23)
  • P107:表を見てようやくApplication層がどんな感じなのかイメージできた。簡単のWebシステムの場合には、ほとんどSERVICEととらえて問題ないかと。 -- sinozaki (2009-11-17 00:45:49)
  • ここまで読んでP72の図を考察すると、1. アプリケーション層がドメインを直接操作していることは望ましくない。「資金移動」のようなユビキダス言語上の認識があればSERVICEがあったほうがよい。2.UnitOfWorkはインフラ層のSERVICEなので存在自体もよい。恐らくアプリケーション層が直接commit()していることはよい。3.ドメイン層がUnitOfWorkを呼び出していることは駄目なんだろうな。恐らく -- sinozaki (2009-11-17 01:01:58)
  • P107: But to put the "transfer" operation on the Account object would be awkward ... → これって、P72:Fig4.1の問題のこと？ -- 村井 (2009-11-18 12:32:34)
  • P106: Application ServiceとDomain Serviceは区別がつきづらい。確かに。 -- kentaro714 (2009-11-18 17:05:59)
  • @murai たぶんそうでしょうが、これってどの辺がawkwardなんでしょう？some global rulesが具体的にどんなものなのかもよくわからず。 -- kentaro714 (2009-11-18 17:10:08)
  • UnitOfWorkまわりが微妙なのは確かにわかるんですが…。 -- kentaro714 (2009-11-18 17:10:52)
  • って、すぐ下に書いてありました。すいませんでした。 -- kentaro714 (2009-11-18 17:12:56)
名前:
コメント:

Granularity

  • [脱線] Medium-grainedとかfine-grainedとか、なんかうまそー -- 村井 (2009-11-18 12:33:51)
  • [Memo] 粒度の小さなサービスは、アプリケーションレイヤでのドメイン間のやり取りを招き、結果としてドメイン知識がドメイン層外部に流出することになる。 -- kentaro714 (2009-11-18 17:15:57)
名前:
コメント:

Access to SERVICES

  • 当時はSINGLETONが主流ですか -- 村井 (2009-11-18 12:35:10)
  • 後半よくわからん。特に、指示詞が何を指しているのか。 -- kentaro714 (2009-11-18 17:32:25)
  • Serviceへのアクセスにsingletonがって話、どういうことかよくわからず･･･ -- 狩野 (2009-12-15 20:59:20)
名前:
コメント:

MODULES (A.K.A. Packages)

  • P110:パッケージ名にドメインに特化した用語が入るのは実は抵抗があるのでは？あまり見かけたことがないです。 -- sinozaki (2009-11-18 00:46:59)
  • @sinozaki DDDサンプルだと、cargo location voyageあたり。ドメインオブジェクトがリッチになれば、「P109: a limit to how many things a person can think about at one」の範囲を超えるのでMODULE化するのでしょうね -- 村井 (2009-11-18 12:44:13)
  • [Memo]P110: 先に決めてしまったモジュールが、内部オブジェクトの進化を妨げてしまうのもよくあること。 -- kentaro714 (2009-11-18 17:39:58)
  • [Memo]P110: 「モジュールは、コミュニケーションメカニズムだ！」 -- kentaro714 (2009-11-18 17:42:13)
名前:
コメント:

Agile MODULES

  • P112: なんだか今のコーディング規約と反することが書いてありますねぇ…＜Javaの例 -- kentaro714 (2009-11-18 17:56:42)
名前:
コメント:

The Pitfalls on Infrastructure-Driven Packaging

  • 長々書いてあるが、結論は「インフラ制約でモデルの自由度を奪うな」ということですね。長いよ。 -- kentaro714 (2009-11-18 18:25:53)
  • p113 last line. どこの国でも修正量が多いと回避しようとするバッドノウハウ？ -- kidotaka (2009-11-29 02:18:26)
  • p116 最後の段落。ルールエンジンを使うとモデル駆動設計は終わるという部分が良く理解出来ない。 -- kidotaka (2009-11-29 06:57:50)
  • Domain層内部のModularityの話が前節くらいにあって、Layerという層のModularityの話がこの節の話ということだけわかった -- 村井 (2009-12-02 12:24:47)
名前:
コメント:

Modeling Paradigms

  • これって2003年ころの話ですよね。今はこのパラダイムは変わっている？ -- 狩野 (2009-12-16 13:57:03)
名前:
コメント:

Why the Object Paradigm Predominates

  • DBに精通してなかったら細かくしすぎで下手こいて、得た教訓が関係性を減らすことだったのかな？ -- kidotaka (2009-12-01 19:11:54)
  • P117 Objects are already understood by ..., *project managers* ホントに？ -- 村井 (2009-12-02 12:26:00)
  • P118 3段落目: fine grained objectsの格納が高コストで問題になったがゆえに、Aggregateの重要性に気づいた、というエピソード。高コストの理由がいまいちピンときてない。 -- kentaro714 (2009-12-02 12:32:48)
名前:
コメント:

Nonobjects in an Object World

  • Prologｷﾀｰ -- kentaro714 (2009-12-16 12:16:10)
  • [Memo]P120: パラダイムをまたがってcoherentなモデルを作るのは難しい。ツールの共存も困難。 -- kentaro714 (2009-12-16 12:26:09)
名前:
コメント:

Sticking with MODEL-DORIVEN DESIGNE When Mixing Paradigms

  • P121 最後の段落 MDDは expressive implementationであることに依存ってこと？ -- 村井 (2009-12-02 12:29:58)
  • P122:選択したパラダイムによりモデルが変わるかぁ -- sinozaki (2009-12-10 21:55:52)
  • P121: マルチパラダイムで最も強力なツールはUBIQUITOUS LANGUAGE。 -- kentaro714 (2009-12-16 12:28:13)
  • @murai MDDはモデルのexpressive implementationを持つことに依存する、つまり、MDDを実践するには、構築したモデルをうまく表現できる実装がないといけない、ということでは？ -- kentaro714 (2009-12-16 14:54:39)
  • P122: RDBも別のパラダイム扱い。 -- kentaro714 (2009-12-16 14:56:51)
  • stickingってどういう意味？ -- 狩野 (2009-12-16 15:01:10)
名前:
コメント:

タグ：

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

下から選んでください:

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