Chapter 6 : The Life Cycle of a Domain Object
AGGREGATES
P126 lack of defined boundaries (in expressivenessか？) 確かにTxが伝播するとかは、表現しずらいかも -- 村井 (2009-12-02 12:32:34)
P126 最後から２行目の boundaryは、Txの話ではなくて、ですよね -- 村井 (2009-12-02 12:33:17)
P129 ふたつめの● AGGREGATE can hold references to other AGGREGATE roots. そうでしょうけど、これまた永続化される|復元される対象とか、どこかに話でてくる？ -- 村井 (2009-12-02 12:35:41)
P129 last paragraph: a technical framework とは例えば？ -- 村井 (2009-12-02 12:36:29)
P126:[comment]データベースのロックを許容しつつテスト可能なプログラミング。対極的な... -- sinozaki (2009-12-13 13:28:49)
P127:6行目 context of root entity ? -- sinozaki (2009-12-13 13:57:03)
P128:root Entity が不変性を保つチェックって具体的にどんな挙動？＜－RootでないEntityはValue Objectに変換する事？ -- sinozaki (2009-12-13 14:34:47)
P128：AGGREGATE内のオブジェクトは他AGGREGATEのrootへの参照を持てる。クラス図で書くと？ -- sinozaki (2009-12-13 14:44:09)
基本的にAggregateってRootが消えたら、同時に消えるっていう要素の集合ですか？(p.129の・A delete ...あたり?) -- fukuhisat (2009-12-16 00:29:18)
ValueObjectは常にAggregateに内包されているのですか？となると、同じAggregate内のVO以外には直接アクセスできないってことですか？VOをあまり理解していなくてすみません。 -- fukuhisat (2009-12-16 00:34:36)
P129:Transient references ～ single operation only だと、なぜbecause以下が成り立つのか？ -- 狩野 (2009-12-16 15:19:58)
P126: はじめてAggregateの言っている意味がわかった気が。一貫性を保たねばならない範囲のモデル表現、だったのか。一貫性を保たねばならない範囲の手続き表現が従来のトランザクションスコープであることと対比するとわかりやすいのね。 -- kentaro714 (2009-12-16 16:08:58)
P126: We need to find a model that leaves high-contention points looser and strict invariants tighter.がわからん。 -- kentaro714 (2009-12-16 16:12:04)
@sinozaki "context of root entity"は、名前空間的なというか、（特定の）root entityに従属するもののうちの～みたいな感じかと -- kentaro714 (2009-12-16 16:19:32)
P129: rootは内部entityの参照を外部に渡せるが、これは一時的なもの…とあるが、この内部entityは変更可能なのか？（変更されるとまずいのでは？）かといって、内部entityを外部にさらせないとなるとメンドクサイ。Aggregateスコープの変更メソッドが欲しい？ -- kentaro714 (2009-12-16 16:47:36)
@murai technical frameworkは、aggregate rootのversin_noをもとに楽観制御するようなのとか？環境を限定すれば、Aggregateの操作に対してsynchronize(root)操作するようなのでもいいかも？ -- kentaro714 (2009-12-16 16:54:25)
@sinozaki "不変性を保つチェック"ではなく、"不変条件が保たれているかどうかのチェック"だと思います。 -- kentaro714 (2009-12-16 16:56:27)
@kentaro714 We need to find a model ～ : high contention(衝突がおこりやすいところ）はlooser、不変条件を厳密にしなきゃいけないところはtighter って感じかな -- 狩野 (2010-01-05 20:31:07) Example : Purchase Order Integrity
P134: なんだか、Deadlock回避だけが例に挙げられているが、Integrityの話って本当にそれだけ？# 体系的に説明してほしい -- 村井 (2009-12-02 12:38:27)
P134:LineItemがpriceを持つのはデータモデルだけで見ていると出てこない発想。この図では Part はEntity ってことでいいのかな。 -- sinozaki (2009-12-13 18:32:57)
このサンプルって最終的に解決って事なのかぁ？確かに price を上にあげたけど、問題にしていたのはquantityだと思っていたのだけれども... -- sinozaki (2009-12-13 18:50:58)
PartはEntityなんですかね？だから、PartのPriceが変わったときにOrderLineに伝搬しないように、OrderLineにPriceを持たせた（？）それってPartをValueObjectにすれば解決したりしないんですかね？ -- fukuhisat (2009-12-16 00:20:21)
話の流れとしては、Lineごとの制御では不足 => PO全体で一貫性が必要 => POが大きいとこれでも不足 => Lineへの自由なアクセスが問題 => AggregateRoot導入 って感じ？ -- kentaro714 (2009-12-16 17:11:51)
@murai Deadlock回避の話って主流でしたっけ？（てか出てましたっけ？） -- kentaro714 (2009-12-16 17:20:28)
@sinozaki PartはEntity扱いなんでしょうね。LineItemがpriceを持つ例は、データモデルの例でもちょくちょく見かけますよー -- kentaro714 (2009-12-16 17:21:19)
@fukuhisat それも1つの解決方法だと思いますが…どちらかというそれは、P134の最後のあたりで書いてある状況に近いのでは？今回は、ビジネスの現状を反映するとこうなる、ということではないでしょーか。 -- kentaro714 (2009-12-16 17:22:39) FACTORIES
P137: 個人的にこのメタファは好き cars are never assembled and driven at the same time -- 村井 (2009-12-02 12:40:20)
↑ だけど、この後の展開では、FACTORYにすべきかどうかは「同時に必要かどうか」は関係ない様子・・・ -- 村井 (2009-12-02 12:41:43)
P139:1の箇がちょっと理解できず。誤訳してそうな雰囲気。 -- sinozaki (2009-12-13 20:46:52)
aggregateを特に強調しているのはなぜ？ -- 狩野 (2009-12-16 15:26:42)
P137~8: 逆に、すべてのObjectのCreationがドメイン的に無意味ト言っているわけではない。その例が「銀行口座の開設」。 -- kentaro714 (2009-12-16 17:29:12)
P139: 2の項はあんまり意識できてなかったかも。最悪個々のEntityごとに具象型持ってもいいよねくらいに思っていた ^^; -- kentaro714 (2009-12-16 17:35:18)
aggregateは生成の単位なのか。 -- 狩野 (2010-01-05 21:25:32)
P139:1 生成メソッドはatomicですべての不変条件を満たすことを強制する。FACTORYはobjectを一貫性を保った状態にのみするべき。きちんと生成できなかったらexceptionもしくは他のメカニズムで、不正なobjectが戻ることがないことを保障する -- 狩野 (2010-01-05 21:31:29) Choosing FACTORIES and Their Sites
P140:2番目の例がイマイチ...BrokerageAccount と TradeOrder の違いを認識できれば理解できるのだが... -- sinozaki (2009-12-13 22:53:41)
2番目の例かなり面白そう。あまり意識してなかった感。 -- kentaro714 (2009-12-16 17:39:43)
2番目むずかしい･･･ -- 狩野 (2010-01-06 17:10:42)
3番目も解説きぼう -- 狩野 (2010-01-06 17:14:13) When a Constructor Is All You Need
P142:3番目はすべての属性が公開されていれば生成を隠ぺいする意味がないからと推測 -- sinozaki (2009-12-13 23:05:50)
P142：JavaのclassLibraryの話はどのへんをみればいいんでしょうか -- 狩野 (2010-01-06 17:22:01)
Java固有じゃなくて、.NETも同じっすよ。IDictionary/Hashtable、IList/ArrayListとか。 -- kentaro714 (2010-01-06 17:41:52) Designing the Interface
P143 last paragraph: Use the abstract type of the arguments, not their concrete classes. 絶対条件なのかなぁ。クライアントからの使われ方しだいのような・・・ -- 村井 (2009-12-02 13:15:33)
P143:後半のクラスの説明のところクラスが断片しか出ていないのでよくわからん。 -- sinozaki (2009-12-13 23:22:09)
項番2番目は、あまり綺麗に守れていなかった感じ。 -- kentaro714 (2009-12-16 17:54:51)
インフラやPresentation依存の引数を渡して良いかどうかはかなり迷ったが、Reconstituteの例からしても、どうもOKっぽい。 -- kentaro714 (2010-01-06 15:17:31)
P143：another good choice～のところがどの図をベースになんの話をしているのかよくわかりません -- 狩野 (2010-01-06 17:30:57) Where Does Invariant Logic Go?
Invariant Logicってどういう意味？ entityを invariant化(もしくはそれを保証)するためのLogic？
前回も出てきたのでもう不要だと思いますが、不変（条件を表す）式や、それを伴なう検査文のことです。 -- kentaro714 (2010-01-05 19:28:37)
最後のあたりは少しわかりづらいですが、要するに、不変式の中には初期化時にしか評価されないものもたくさんあるので、そういうものはProductではなくFactoryにあってもいいよね、という話。 -- kentaro714 (2010-01-06 15:16:42) ENTITY FACTORIES Versus VALUE OBJECT FACTORIES
結局は automatically なのは sequence なのね... -- sinozaki (2009-12-14 20:37:34)
@sinozaki とは限らないです。お馴染み採番テーブルもありますし、GUIDも候補としてよく見ます。実際に使ったことはないですが。 -- kentaro714 (2010-01-05 19:38:40)
P145:最上段 Factoryは何かインフラ中立というか、インフラにも依存しないイメージがあったけど、そうでもないのね。 -- kentaro714 (2010-01-06 15:15:51) Reconstituting Stored Objects
P145 "2": repairing such inconsistencies(rule violation), make (it) more challenging って、どんなruleだろう。なんとなく分かる気もするが、例がほしい -- 村井 (2009-12-02 13:25:24)
で、Fig6.16-17は上記の例にはなってない。というか、何が言いたい例？ツッコんだら負け？ -- 村井 (2009-12-02 13:26:12)
P145:Fig 6.16 を Repository と呼ばない理由はなにかあるのかな？<-最後に書いてありましたねぇ。 -- sinozaki (2009-12-14 20:56:10)
どちらかというと、ここの例がreconstituteの例、ってこと？だとすると、いろいろ例を仮想はできそう。 -- kentaro714 (2010-01-06 15:14:54) REPOSITORIES
P147:最初の middle of its life cycle . では end of life cycle はいつなのか。読んでいくうちにわかったらいいな。 -- sinozaki (2009-12-15 00:15:28)
渡辺さんがNexti で書いていたけど、Dao と REPOSITORY を違うものとして見ないといつまでも理解できない気がする。とくに追加系のメソッド(addXX)をいつ呼ぶのがいいのだろうか。SQLを発行したい時ではないことなのかと思っている。 -- sinozaki (2009-12-15 00:24:23)
P148：最後の段落の前までのところで何が言いたいのかわかりませんでした。あとtraversalってどう訳すとわかりやすい？「by traversal」とかちょっと掴めない -- sinozaki (2009-12-15 00:43:35)
P151: 2nd p. A REPOSITORY represents all objects of a certain type as *a conceptual set*. -- 村井 (2009-12-15 12:33:03)
↑以降も何度か出てくるけど、REPOSITORYは、概念的にはObjectの集合を表す。(via @kentaro714) CargoRepositoryなら Cargoの集合。 -- 村井 (2009-12-15 12:34:27)
@sinozaki "end of life cycle"はObjectが消える時なので、通常はDBからDELETEした時だと思います。 -- 村井 (2009-12-15 18:32:33)
@sinozaki "traversal" は直訳だと横断だけど、directory traversalという言葉があるように、なにかの対象を順番に総当たりするようなニュアンスを含んでいるように思います -- 村井 (2009-12-15 18:34:35)
P149:traversableはmuddling the modelなのでnegativeな意味なのかな。 -- 狩野 (2009-12-16 15:43:43)
@sinozaki @村井 僕はわりと、「走査」と訳したりしてます。＜traversal -- kentaro714 (2010-01-05 17:30:34)
ここだと、手でたどっていくような感じかなぁ。 -- kentaro714 (2010-01-06 17:39:56)
イイネ! > 「走査」 -- @kentaro714 (2010-01-08 18:59:35)
[参考][英語] REPOSITORYは比喩的に「（情報･天然資源の）宝庫」の意味でも使われる 引用from http://getupenglish.blog.ocn.ne.jp/getupenglish/2009/12/repository.html -- 村井 (2010-01-08 19:00:43)
P148:Indeed～ forget this reality. this realityってなに？ -- 狩野 (2010-01-20 15:11:01)
P148:最後 By the time～the model focus is gone. のところがメッセージな気が。 -- 狩野 (2010-01-20 15:14:20)
P149:最後 Aggregate内部のObjectはroot以外からのアクセスを禁止するのが大事 -- 狩野 (2010-01-20 15:24:40)
P149:図の下 in terms of the model がポイント -- 狩野 (2010-01-20 15:41:32) Querying a REPOSITORY
汎用Criteriaを使ったRepositoryをSecification basedと言っているのがいまいちしっくりこないが、どうせ後で話があるみたいなのでまぁいいかという気分。 -- kentaro714 (2010-01-06 17:43:18)
LINQってRepositoryに使えそうな気がする -- 狩野 (2010-01-20 15:48:02) Client Code Ignores REPOSITORY Implementation;Developers Do Not
P154:[コメント]隠蔽化しても挙動を把握していること。自動化祭り...というのは冗談だが、どちらかというとこの責務は提供する側に待たされることが多いのはいいことではないのでしょうね。 -- sinozaki (2009-12-15 21:31:55)
補足っぽい項だなあ。書いてあることはまあそのとおりで納得なのですが -- 狩野 (2009-12-16 15:51:41)
設計判断ということか。 -- 狩野 (2010-01-20 16:02:32) Implementing a REPOSITORY
Working Within Your Frameworks
要するに、EJB Homeダメだっつーことで -- 村井 (2009-12-15 12:42:23)
アンチパターンとしてのEJBに興味がわいてきた。おらわくわく（ry -- 狩野 (2009-12-16 15:54:57)
EntityBeanのライフはもうゼロです。 -- kentaro714 (2010-01-06 18:06:00) The Relationship with FACTORIES
P158: 先述のmiddle of its life cycleをFig6.22,23で表している。beginingは FACTORY。 -- 村井 (2009-12-15 18:38:46)
p.158, 図6.22: 結局databaseにselect queryを投げた後は、EntityとかVOを再構築するんだからFactoryを呼ぶってこと？表紙の裏の図ではRepositoryとFactoryに関連はあまりなさそうですが。。 -- fukuhisat (2009-12-16 00:39:37)
P158:オブジェクトの生成(factoryの責務)とDBから既存をobjectを見つけだすことを区別することが重要。 -- 狩野 (2009-12-16 16:04:59)
位置づけがいまいちしっくりきてないのだけども、「概念的に新たなオブジェクトを作り出す」ことが責務であるFactoryを、「技術的に新しいオブジェクトを作り出す」ために再利用している、ということ？ -- kentaro714 (2010-01-06 18:18:51)
P158:last paragraphがよくわかりません。find or createを避けるべき理由は？ -- 狩野 (2010-01-20 17:01:55) Designing Objects for Relational Databases
P160:1行目 To do otherwiseはmodelとimplementationのtight couplingを失うリスクがある。ここで(1)otherwiseはrichness of the modelの反対という理解でOK？ (2)modelとimplementationは疎結合がよいのでtight couplingではよくないのでは？ ここよくわかりません -- 狩野 (2010-01-20 17:13:17)
シンプルなのがよいということか -- 狩野 (2010-01-20 17:21:58) 最終更新：2010年01月20日 17:21
