Chapter 12 : Relating Design Patterns to the Model
- イメージ的には、DDD全体でなんども出てくる「テクニカルなコンセプトをドメインに持ち込む」シリーズ。Continuous Integration然り、Domain Refactoring然り。 -- kentaro714 (2010-09-01 16:17:23)
STRATEGY (A.K.A POLICY)
- P313:Service の肥大時によくやる感じの事でしょうかね。 -- sinozaki (2010-08-08 22:55:56)
- P311、3段落目:mixed in with the rest of behaviorの程度がひどくなるにつれ、選択(根拠?)が曖昧になる -- 狩野 (2010-09-01 08:27:36)
- P311、最後:頻繁に変わる部分と変わらない部分を分離する! -- 狩野 (2010-09-01 08:29:50)
- P313:ここで安易にServiceのサブクラスを作らないところが良い。 -- kentaro714 (2010-09-01 16:18:29)
- P313:しかし、なんというかProcessとかPolicyとかSystemとかそういう概念はもう少し一般化して持ち込んであげてもよかったんじゃないかと思うのだけど。ビルディングブロックとの違いはなんなのだろうか。 -- kentaro714 (2010-09-01 16:20:02)
- Strategyが必ずPolicyになる、というのもなんとなくしっくり来ないところはある。今回はそういう定義だということで無理やり納得してもいいのだけど。 -- kentaro714 (2010-09-01 16:20:30)
- @masakanou P311の2段落目で曖昧になるのは、選択ではなくthe actual behavioral alternativesの方ですね。 -- kentaro714 (2010-09-01 19:14:46)
COMPOSITE
- P319:ひとつ気になったのは、Transport Leg を持たない Door Leg などの用途がイメージしずらかった。 -- sinozaki (2010-08-09 00:14:55)
Why Not FLYWEIGHT?
最終更新:2010年09月01日 19:14