IsolatingtheDomain

Ⅱ : The Building Block of a Model-Driven Design

• P64:Wirfs-Brock は「オブジェクトデザイン」の著者。（読んでないけど） -- sinozaki (2009-10-13 21:56:09)
• P65:『MODEL-DRIVEN DESIGN』と『SMART UI』の「mutually exclusive choices」は「相関しあわない関係」位の意味？ -- sinozaki (2009-10-13 22:15:23)
• P65:『AGGREGATES』と『FACTTORIES』の「encapsulate with」は読めばわかるのかな？ -- sinozaki (2009-10-13 22:16:59)
• P64:Larmanは「実践UML」 -- 狩野 (2009-10-20 20:59:39)
• [memo]"Developing a good domain model is an art.” 態度がいさぎよくてよい。 -- kentaro714 (2009-10-21 12:22:05)
• しかし、より細かい要素はシステマティックになり得る。自分の認識とほぼ同じ。ソフトウェア科学の出番はこのあたりに大いにある。 -- kentaro714 (2009-10-21 12:24:00)

Chapter 4 : Isolating the Domain

• P67:Domain-driven point of viewが次から展開されるという理解でいいのかな -- 狩野 (2009-10-21 16:22:03)

LAYERED ARCHITECTURE

• P70:本書ではないが、JavaEE勉強会のサイトではApplication Layerについて「ビジネスルールや知識を含まない。」と記載があるが、言い過ぎでありませんか？(英語力が拙く申し訳ない...) -- sinozaki (2009-10-13 22:54:16)
• P70:Infrastructure layer はUI widgets の　Drawingにも使用。 -- sinozaki (2009-10-13 23:00:40)
• P70:下部3行の The domain object...で始まる文の文意がとれず。ここで言う The domain object はDomain Layer に属するものと取ってよいのか -- sinozaki (2009-10-14 00:20:50)
• P72:(機械翻訳)それ自体、穏やかに、そのドメインを隔離しないという問題を例証します。 要求からトランザクションコントロールまでのすべてが含まれなければならなかったので、ドメイン層は総合的な相互作用を続くほど簡単に保つためにレベルを下げられなければなりませんでした。 私たちが孤立しているドメイン層のデザインに焦点を合わせられるなら、そのドメインの規則をよりよく表したモデルのためにページの上と、そして、頭にスペースを持っているでしょうに、おそらく、原簿かクレジットと借り方オブジェクトか、金融取引オブジェクトを含んでいます。 -- sinozaki (2009-10-14 00:56:23)
• P68:上向き矢印は「some indirect mechanism」(observerの通知的な） -- 狩野 (2009-10-21 16:39:37)
• P70:下部3行は「ドメインオブジェクトはドメインモデルを表現することに注力できる、～から解放されることによって」という感じかな -- 狩野 (2009-10-21 16:53:32)
• P71:Example:セキュリティ省いていいんかいなと。 -- 狩野 (2009-10-21 16:58:28)
• P72最上部:ここすごく意味がとりづらい。これは、説明のためにシンプルにしすぎたのが問題だと思ったのだが、これがdomainを隔離していないことになっているのか？ -- kentaro714 (2009-10-21 17:12:41)
• P72: ... with design dependencies in only one direction. 依存関係の話がどこかでありましたが、これですね -- 村井 (2009-11-04 12:21:45)
• P72:the domain layer had to be dumbed down(やさしく書く直す）だから、隔離していないと読みました -- 狩野 (2009-11-04 15:05:49)

Relating the Layers

• P74:２行目の「Some technical components」が指しているものはなにか？ -- sinozaki (2009-10-14 01:35:21)
• 直下の"to directly support the basic functions of other layers"なものや、"provide the mechanisms for them to relate"なものですね。丸括弧内に書いてあるのが、さらなる具体例です。 -- kentaro714 (2009-10-21 17:23:39)
• P73: main benefitは Versatilityではなく simplify, narrowly focused on its jobですね。 -- 村井 (2009-11-04 12:24:19)
• p72:パターンのmotivationはlayerのbenefitを失わずにconnectすることだ、というのはなるほどなるほど。 -- 狩野 (2009-11-04 15:13:34)
• P74:最初の段落解説希望 -- 狩野 (2009-11-04 15:22:11)

Architectural Frameworks

• 何気に結構重要な話では。プロジェクトでは理由と制約が逆になってます。 -- sinozaki (2009-10-14 01:51:14)
• すごく重要だと思う。特に、1段落目のラストとP74の一番下。 -- kentaro714 (2009-10-21 17:24:59)
• P74: 下から4行目 generic Java objectsとは今でいうPOJOと思われ。Genericsではないよね -- 村井 (2009-11-04 12:27:41)
• P74:フレームワークに使われるなよ！ -- 狩野 (2009-11-04 15:34:21)

The Domain Layer Is Where the Model Lives

THE SMART UI "ANTI-PATTERN"

• P77:Advantages の一行目 Productivity が高いことだけに惑わされない事を強調したい。 -- sinozaki (2009-10-14 21:40:48)
• P77:Advantages の最後行、「変更の影響が局所化されているからすばやくredoできる」っていうのは本当ですか？ -- sinozaki (2009-10-14 21:49:31)
• ただ、個人的にはクラサバの時代と比べると"SMART UI"に相当するものは減ったと思っています。 -- sinozaki (2009-10-14 22:10:09)
• redo portionsてのはコピペみたいなものでは？ビジネスロジックが各UIにlocalizedly実装されているので、side-effectの面ではある意味メンテしやすいという考え方もありますし > sinozaki -- 村井 (2009-11-04 12:30:49)
• [Memo]P76上段 "Many software projects do take and should continue to take a much less sophisticated design approach that I call the SMART UI." 多くのプロジェクトでは、SMART UIの方が良い、と言っている点に注意。 -- kentaro714 (2009-11-04 14:46:54)
• portions they can't figure out, つまり、よくわかんなくなったところを元に戻せる、ってことですよね。ドメイン層のオブジェクトが共用されている場合は、他の機能に影響があるので、テストなしでは進むのも戻るのも難しそう。 -- kentaro714 (2009-11-04 14:51:34)
• @shinozaki P79によると、Transaction ScriptはSmart UIやLayered Architecture（≒DDD）と異なる解決策としてあげられているので、そういう意味では減っているかと思います。 -- kentaro714 (2009-11-04 14:54:34)
• p76:unsophisticated team で complex project なんですがどうすればいいですか -- 狩野 (2009-11-04 15:52:41)

Other Kinds of Isolation

• 想定問答でしょうが、結果的にはずいぶん先への導入になっているだけですね。 -- kentaro714 (2009-11-04 14:56:15)