Chapter 7 : Using the Language: An Extended Example
昔読んだときは、「なんだこれ？」と思ったけど、読み返すとわりと良い例な気がしてきた。 -- kentaro714 (2010-02-01 16:44:30) Introducing the Cargo Shipping System
P164:スンません。何気に Cargo の限定子で role となっている?解決 different role ということですね。逆に限定子のいい使い方の例かと。 -- sinozaki (2010-01-24 22:15:13)
P164:Delivery Specification と Carrier Movements に関連がないのはなぜか？解決恐らく destination と to が等価のオブジェクトなんだろうな。 -- sinozaki (2010-01-24 22:23:53)
P165:Handling Event と Carrier Movement の違いが今のところ認識できず。0..1なっている理由も今のところ。 -- sinozaki (2010-01-24 22:57:26)
@sinozaki DeliverySpecificationとCarrierMovementには、意味的にはおそらくあまり関係ないと思います。これは、CarrierMovementの意味が明らかになればほぼ自明です。DeliverySpecificationと関連が深いのは、図中のノートにあるようにDeliveryHistoryです。Specificationのプロトコルを考えてみると、DeliveryHistoryへの（永続的な）参照は不要です。 -- kentaro714 (2010-02-01 16:49:11)
@sinozaki 話が前後しますが、CarrierMovementは、例えば運送業者による運送作業そのものを表します。XXX運送が神戸港から横浜港まで荷物を運びました～ってのがCarrierMovementです。これは、個々のCargoには直接関係しません。HandlingEventは、特定のCargoの扱い（移動とか積み下ろしとかだと思う）を表していると思われます。HandlingEventからCarrierMovementへの参照が0..1なのは、おそらくですが移動をともなわないイベントがあるんじゃないでしょうか。同じ場所で倉庫に入れたり出したりなど。 -- kentaro714 (2010-02-01 16:55:25)
P163のrequirements3の話が出てこないが･･･後から出てくるのかな -- 狩野 (2010-02-02 14:44:05)
モジュールの話で少しだけでてきてたけど詳細の説明はなし -- kentaro714 (2010-02-03 18:58:21) Isolating the Domain: Introducing the Applications
P167:They should not work out the answers to the questions they ask.自分で問題を解決しちゃうな？解決はdomain layerに任せて調整に徹しろということ？感覚的にはわかるが･･･ -- 狩野 (2010-02-02 14:50:15) Distinguishing ENTITIES and VALUE OBJECTS
P168:Locationのところがよくわからず。同じportCode=同じ場所=valueObjectと捉えたのだが -- 狩野 (2010-02-02 15:10:16)
@狩野 同じ名前でも場所が異なりうるとの話があるので、地名みたいなプロパティが省略されているのかな？と思います。地名や属性で同一かどうか決められない=ENTITIY。で、portCodeはEntityの IDですね -- 村井 (2010-02-03 12:05:12) Designing Associations in the Shipping Domain
P169:あれだけ言って循環参照ですか。ただまだ HandlingEvent とDeliveryHistory が上手く認識できていないので、なにか策があるのかな、LazyLoadとか... -- sinozaki (2010-01-25 01:06:11)
Figure7.2:CargoとDeliverySpecificationの関連のメモでの主張したいことがよくわかってません。より関連があるのはわかるが特にここまで説明がないようだが。 -- sinozaki (2010-01-25 01:11:15)
@sinozaki 循環参照の実装上の問題は、Queryを使うことで回避する、というシナリオのようです。 -- kentaro714 (2010-02-01 16:57:42)
@sinozaki まずは、DeliverySpecificationがCargoを参照すべきでない、ということが主な意図ではないでしょうか。より関連があるのは～の部分は補足かなーと思ってました。 -- kentaro714 (2010-02-01 16:58:51)
Figure7.2:CargoとDeliverySpecificationの関連のメモ:DeliverySpecificationがDeliveryHistoryとモデル上深い関係があるなら、それをモデルで表す必要があるのでは？ -- 狩野 (2010-02-02 15:58:48)
Figure7.2:Locationのところのメモ：ここを読むと(Userをtrackingしなくていいなら）やっぱりLocationはVOでいいのではないかと･･･ -- 狩野 (2010-02-02 16:06:38)
repositoryへの期待が高まる･･･ -- 狩野 (2010-02-02 16:08:35) AGGREGATE Boundaries
P171:ひとつめ(to find the Handling Events for a Delivery History) のところが...local within the Cargo AGGREGATE だから？ -- sinozaki (2010-01-25 22:12:50)
Handling Event のライフサイクルは、必ずしも Cargo に依存していないから Boundaries の外側という理解でいいのかな。 -- sinozaki (2010-01-25 22:16:01)
P170:いきなり英語わかりづらい… -- kentaro714 (2010-02-01 17:02:07)
@sinozaki これは先程の、循環参照を切るために、コレクションを使った参照をデータベースクエリに置き換える検討をした、という話の再掲ですね。 -- kentaro714 (2010-02-01 17:07:10)
@sinozaki HandlingEventは、Cargoと切り離して考えたとしても、意味のある活動だから…すなわち、グローバルアクセスが必要と判断したから、というのが1つありそうです。図中のLow-Contention Transactionが必要という部分はよくわからず。 -- kentaro714 (2010-02-01 17:09:27)
HandlingEventは頻繁に操作されるから…という話だとしても、Cargoと同じAggregateに入れたからといってそんなに競合が起きる気もしないんだけどなぁ… -- kentaro714 (2010-02-01 17:11:41)
↑同じく、low-contention transactionにこの段階でこだわる必要があるのかが不明。モデルと関係なくね？ =>♪DDD-jpに相談だ -- 狩野 (2010-02-02 19:12:38)
Aggregateの粒度はP131からの競合の話がありましたね -- 村井 (2010-02-03 12:07:13)
個人的にはP167最後～P168にあるように、same Cargo cannot be both loaded and unloaded at the same timeとあるので、mou -- 村井 (2010-02-03 12:09:20)
↑牛かっ！ もう、low-contention transactionと決めつけてましたが。 -- 村井 (2010-02-03 12:10:09) Selecting REPOSITORIES
P173:Handling Event は難しい。to find out what has been load onto aCarrier Movement. 必要になったらREPOSITORYを作ればよいということはわかるが... -- sinozaki (2010-01-25 22:38:26)
@sinozaki このモデルでは、関連はHandlingEvent→CarrierMovementになっていますよね。もし特定のCarrierMovementに積み込まれるCargoが必要になった場合、この参照では辿れないので、HandlingEventのグローバルアクセス（findBy(ID schedule)みたいなの）が必要になるから、そうなるとRepositoryが必要になるね、だけどそんな要件はないからまだいらないね、と言っているわけです。 -- kentaro714 (2010-02-01 17:19:26) Walking Through Scenarios
P174:2行目:because以下が理解できず。AggregateBoundaryの外のentityだから古いcargoObjectが参照していたのと同じCustomerへの参照が必要？ -- 狩野 (2010-02-02 20:04:41)
↑理解した。同じCustomerが繰り返し予約という文脈なので古いCustomerへの参照が必要なのですね -- 狩野 (2010-02-02 20:09:12) Object Creation
P176:最初の段落がわからないです。そもそも eventType はどういう分類で表現されるものなのでしょうか。もしかして状態遷移図のイベントと同粒度で考えてもいいのでは？ -- sinozaki (2010-01-26 00:57:08)
これ、面白い疑問だと思います。仮に、HandlingEventによってCargoの状態が変わるように認知/設計した場合には、Cargoの状態遷移モデルのイベントとして現れる可能性があります。しかし、今回はCargoの状態はCargo自身が直接管理しません（DeliveryHistoryを見れば間接的にわかりますが）。そもそも関心対象ではないと見るのが妥当かと思います。 -- kentaro714 (2010-02-01 17:39:27)
P176: 2番目の段落の2行目の「HistoryEvent」は、「HandlingEvent」の間違いですよね。 -- kentaro714 (2010-02-01 17:41:25)
P174:この項最初:FACTORYなのにprimitiveConstructorが必要というのがよくわからん。prototypeパターンのclone()のこと？ -- 狩野 (2010-02-02 20:20:26)
P175:thisを引数にしたnewなんてできるのね。 -- 狩野 (2010-02-02 20:30:13)
P174:下から5行目付近 null Delivery Specification。これは以前利用したCargoをテンプレ的に利用ってことなんだけど、Cargoって便みたいなものだと思ってたんで、届け先をnullにしちゃうのが意外。Cargoという概念を間違えて捉えてる可能性が>自分 -- 村井 (2010-02-03 12:13:39)
HandlingEventのIDはCargo.ID、時刻、eventTypeとある。先にload/unloadは同時には起きないとあったが、それ以外にもeventTypeがありえて、同時に起きえるということか -- 村井 (2010-02-03 12:15:33)
↑次のページに sealing, storing, and other activitiesとあったので、そういうことなのか。 -- 村井 (2010-02-03 12:16:18)
あ、Cargoは 「便」じゃなくて「荷」ってことか。 -- 村井 (2010-02-03 14:46:47) Pause for Refactoring: An Alternative Design of the Cargo AGGREGATE
P177:２段落目のところは DeliverHistoryが HandlingEventをadd する事でいいのでしょうか？ -- sinozaki (2010-01-27 01:12:37)
「場合による」のはいいが実体(List)を持つのか、EventのIdentifyをもつのかの話をもう少しブレイクダウンしてほしい。オブジェクトの load, unload だけが観点でない気がする。後者の場合、DeliverHistory がRepository に依存することになるのでそれによるデメリットあるかと思うが。とグチグチ -- sinozaki (2010-01-27 01:38:52)
P177:2段落目: HandlingEventの追加に伴ってDeliveryHistoryを更新する際には、Cargo（Aggregate）を同じトランザクションに参加させることになる。 -- kentaro714 (2010-02-01 17:49:49)
↑で、とりあえずLow-contentionなTransactionのあたりの仮定は理解。 -- kentaro714 (2010-02-01 17:50:38)
結局、DeliveryHistoryはなくなるの？Entityとして存続してるっぽいけど、存在意義は概念の明確化？ライフサイクルを通じた操作がいまいちイメージできてない。 -- kentaro714 (2010-02-01 18:07:02)
あ、でもDeliveryHistoryに問い合わせなきゃいけない操作は結構あるから、別にこれでいい気がしてきた。 -- kentaro714 (2010-02-01 18:08:59)
P179:2nd paragraph: explicit colleciton is ... much faster then a REPOSITORY query. これ、なんのこと？ ずっとCollectionをメモリで持ってる？永続化してるなら、それをCollectionに復元する性能もあるのに、getterだけの性能で言ってるということ？ -- 村井 (2010-02-03 12:19:51)
@kentaro714 そんな話出てきた？>結局、DeliveryHistoryはなくなるの？ -- 狩野 (2010-02-03 14:07:27)
P179:2段落目:all changes are encapsulated within the Cargo's Aggregate boundary とあるけど、repository追加はAggregate外ですよね。ということでこの段落（最後）がなにが言いたいのかよくわかってません -- 狩野 (2010-02-03 14:10:45) MODULES in the Shipping Model
インフラレベルのプラクティスをモデル/コンセプトに昇華させるシリーズ。 -- kentaro714 (2010-02-01 18:27:43)
dtoとかpackage作ってスミマセンデシタ。もうしません、とは言い切れない。。 -- 村井 (2010-02-03 12:20:49)
P179:willy-nilly = Will I, nill I ? = Will I,not to will I -- 狩野 (2010-02-03 14:15:21) Introducing a New Feature: Allocation Checking
P185:二つの SERVICE は deriveEnterpriseSegment と mayAccept -- sinozaki (2010-01-28 00:47:59)
EnterpriseSegmentの導入判断がうさんくさすぎる。カテゴリの抽象として導入して、概念を明確にしているのはいいんだけど、ここは単にCategoryで良かった場面では？やりすぎ感ただよいまくり。 -- kentaro714 (2010-02-01 18:40:18)
最初読んだときはいまいちよくわからんかったけど、今回はすっきり。yield managementの意味をしっかりおさえながら読むべし。 -- kentaro714 (2010-02-01 18:41:44)
@sinozaki 正確にはたぶん、SERVICEはAllocationChecker1つで、メソッドが2つある形ではないでしょーか。 -- kentaro714 (2010-02-01 18:50:36)
EnterpriseSeqmentってクラスとな？？ なんなんだろ。class Entity{ Value value;}くらい何者かわからん -- 村井 (2010-02-03 12:29:18)
yield management:需要を予測して、最適なタイミング・価格で、適切な顧客層に商品・サービスを販売する手法。スーパーが閉店間際に半額にしたりとか。（例がいまいちかな） -- 狩野 (2010-02-03 14:28:12)
P184: 最後行 isn't clearだから？UBIQUITUS LANGUAGEでないから？ こう呼ぶの？ > Enterprise Segment -- 村井 (2010-02-03 14:53:45)
Cargoインスタンスの分類・分界・補集合という意味？システムの境界(ANTICORRUPTION LAYER的)の意味？ > Enterprise *Segment* -- 村井 (2010-02-03 14:59:11)
P183:アナパタ！で1Chapterあるのかー。買うべきか -- 狩野 (2010-02-03 17:00:36)
P184:Noticeのところが何をいっているのかわからず -- 狩野 (2010-02-03 17:06:52)
P184:EnterpriseSegmentは分かっている前提ですかそうですか。（一気に何言ってるかわからなくなりました･･･） -- 狩野 (2010-02-03 17:18:10) A Final Look
ここまで読んで Allocation Checking の意図はギリギリ伝わった。Enterprise Segument がもう少し具現化されていないとわかりずらい。 -- sinozaki (2010-01-28 01:11:48)
先の疑問は、Cargoインスタンスの(あるビジネス的なコンテキストにおける)分類・分界・補集合という意味であると理解した。P186 2nd段落6行目 The same ENTITIES could be segmented differently for different purposes. -- 村井 (2010-02-03 15:04:07)
enterprise integration patternsにはこういう話が書いてあるのかな？ -- 狩野 (2010-02-03 17:20:55) 最終更新：2010年02月03日 18:58
