domaindrivendesign @ ウィキ
domaindrivendesign @ ウィキ

MakingImplicitConceptsExplicit

Chapter 9 : Making Implicit Concepts Explicit


Digging Out Concepts

名前:
コメント:

Listen to Language

  • なんかDeveloperが突っ走ってる気がするけど･･･ -- 狩野 (2010-02-17 22:22:17)
  • P209: You mean it isn't that way now ?! オー！ナンテコッタイ！ -- 村井 (2010-04-15 12:27:00)
  • Routing Serviceが cargo_bookings tableを populateする役割だったが、Itineraryオブジェクトをただ返せばいいんだ！ と気がついたことはわかった。これがDEとの対話で導き出されるべきことなのかが良く分からないけど。 -- 村井 (2010-04-15 12:29:24)
名前:
コメント:

Scrutinize Awkwardness

  • 発生主義（はっせいしゅぎ、accrual basis）とは会計原則の一つで、現金の収入や支出に関係なく、収益や費用の事実が発生した時点で計上しなければならないとするもの。収益と費用を現金の受け渡しの時点で認識する会計原則である現金主義とは反対の概念である。 引用元→ http://ja.wikipedia.org/wiki/%E7%99%BA%E7%94%9F%E4%B8%BB%E7%BE%A9 -- 村井 (2010-04-15 12:23:23)
  • 発生主義にすることで、当初考えていた現金主義のInterestCalculatorは不要になり、ただの履歴から導出すればよいことになりました -- 村井 (2010-04-21 17:23:10)
  • P217.L1: 全ての矛盾を解決できるわけではないし、それが望まれてすらいない場合もある...続きはCh14で。が気になる -- 村井 (2010-04-21 17:31:48)
  • ↑ コメント先まちがえました。下のContemplate Contradictionsのトコです -- 村井 (2010-04-21 17:32:29)
名前:
コメント:

Contemplate Contradictions

  • ガリレオの「それでも地球はまわっている」の話なのだが、中途半端にまとめられ、「オーケー. われわれの矛盾はこれほど興味深いものではないが・・・」などと現実に話を戻してしまう流れ -- 村井 (2010-04-21 17:29:25)
  • 矛盾（対立）に立ち向かう話は ゴールドラット博士のシリーズのザ・ゴール２やザ・チョイス を思い出します -- 村井 (2010-04-21 17:42:07)
名前:
コメント:

Read the book

  • P219.L1-: アナパタより Reusable Object Models。off-the-shelfではないけどね -- 村井 (2010-04-21 17:50:37)
名前:
コメント:

Try,Try Again

  • 銀の弾丸はないので、どんどんミスを恐れず試そう -- 狩野 (2010-02-17 23:56:46)
名前:
コメント:

How to Model Less Obvious Kinds of Concepts

名前:
コメント:

Explicit Constraints

  • P221:呼び出し元がsimpleになるのはいいな。制約の複雑さがカプセル化されてる感じ -- 狩野 (2010-02-18 00:12:48)
名前:
コメント:

Processes as Domain Objects

  • DomainExpertが話したことはexplicitに。computerProgramのメカニズムは隠蔽する -- 狩野 (2010-02-18 00:31:31)
名前:
コメント:

SPECIFICATION

  • P226:Specificationは述語オブジェクト。独り言ですがこれって直観的には抽出しずらいかと -- sinozaki (2010-05-11 02:00:20)
  • P234:Generating の例は Factory のオブジェクト生成ルールを Specificaion としている位と取れた -- sinozaki (2010-05-11 03:19:30)
  • P226:下 Providing～の意味がわからないっす -- 狩野 (2010-05-12 17:51:57)
名前:
コメント:

Applying and Implementing SPECIFICATION

名前:
コメント:

Validation

  • フツウといいますか…一番基本的でわかりやすい使い方。対象データがオンメモリにあれば、Filterとしても使える。これが、次のSelectionにつながる。 -- kentaro714 (2010-05-11 15:02:55)
名前:
コメント:

Selection

  • どの解決策も中途半端に見えて消化不足。 -- kentaro714 (2010-05-11 13:41:41)
  • とはいえ、SpecificationとSQLとの相互変換ができない以上、しょうがないのか。OODBやOOなクエリが書けるORMでも、そのクエリで直接扱えなければ同じだしなぁ。オンメモリにのっけてからフィルタ、というのが性能的に許容できない以上、DBの深層部分にまでフィルタメカニズムが食い込む必要があるわけで、これはどう見ても苦しい話。 -- kentaro714 (2010-05-11 13:44:03)
  • Spring＋iBATISやSpring＋JPA(Hibernate)なインフラではどうなるのだろう。JPAの場合はJPQLにマッピングされるだけで、ほぼ同じか。iBATISの場合は、クエリ組み立てをSqlMapでやろうとするとasSqlアプローチは無理なので、2番目か3番目のアプローチになるんだろうなぁ。他にはある？ -- kentaro714 (2010-05-11 13:46:43)
  • しかし、これを読むまでSpecificationにRepositoryを渡してコールバックさせる、という発想はなかった。 -- kentaro714 (2010-05-11 13:48:20)
  • JavaEEで読んでいる時は、2番目の解決策をDouble Dispatchと言っていたけど、違うのでは？Wikipediaの「In software engineering, double dispatch is a mechanism that dispatches a function call to different concrete functions depending on the runtime types of multiple objects involved in the call.」この記述に従うと、Runtimeのオブジェクト型に応じてディスパッチしているのはRepositoryのメソッドだけなので、これはSingle Dispatchの単なるメソッド選択なんじゃないかなぁ。それとも、広義にはこれをDouble Dispatchと言ったりするのだろうか？ -- kentaro714 (2010-05-11 14:59:55)
  • >Double Dispatch http://d.hatena.ne.jp/asakichy/20091203/1259800158 -- 村井 (2010-05-12 13:54:35)
  • ↑Double Dispatchの目標は、「2つのオブジェクトの組み合わせ」によってある１つの呼ばれるメソッドが決まる ということだとすると、上記サイトの例では 図形(Rectanble, Oval)と 描画(Brush, Penとか？)の組み合わせだし、本の例は、SPECIFICATION と InvoiceRepository(普通に考えて多態性はなくてひとつと思うが) -- 村井 (2010-05-12 14:05:01)
  • http://java-house.jp/ml/archive/j-h-b/014912.html <- 下の方に引用されている高木氏のメールにDouble Dispatchの説明あり（Visitorまで読まなくてOK） -- 村井 (2010-05-12 14:07:09)
  • そもそもJPAのEntityはドメインレイヤのオブジェクト？ だとすれば JPQLは（SQLにかなり近いが）オブジェクトに対するQueryの記述なので、決してテーブル構造がドメインレイヤに漏れているわけではありません（汗 -- 村井 (2010-05-12 14:25:33)
  • JPAだとQueryObjectもあるでよ確か -- 村井 (2010-05-12 14:27:35)
  • 設計面はともかく…実装的にQueryObjectなら、SPECIFICATION同士のAND/ORなどをそのまま表現できそう。JPAのAPIはイケてないので、そうはいかないかもしれないが。 -- 村井 (2010-05-12 14:39:06)
  • ↑ QueryObjectは、例１と同じで、asSQL()の代わりに asQueryObject()とする案です。 -- 村井 (2010-05-13 09:52:42)
  • 結局は、ORMが *ドメインモデル*のオブジェクト と RDBを *本当に* マッピングしてくれるのであれば、JPQLでもQueryObjectでも、ドメインレイヤを汚していないと言っていいのかもだけど。 -- 名無しさん (2010-05-13 09:55:09)
名前:
コメント:

Build to Order

名前:
コメント:

Example:Chemical Warehouse Packer

  • P236～7:かなりわかりづらくないすか？drumのContainerSpecificationは、Chemicalからたどって取るんですよね。うっかり適当に読んでいくと、isSafelyPackedのコードがなんのこっちゃ状態になった。 -- kentaro714 (2010-05-11 16:17:28)
  • ContainerFeature はただの Value Object になるのかな。Chemical にsetContainerSpecification() があることに違和感。恐らくDrum にもあるのでしょうかね。 -- sinozaki (2010-05-12 00:59:29)
  • >kentaro714 drumのContainerSpecはそうだと思う。クラス図に従えば、(プロパティはテキトーだけど)→ drum.getChemical().containerSpecification().isSatisfiedBy(this) -- 村井 (2010-05-12 15:18:07)
  • >sinozaki Chemical(薬物とか？)を格納するコンテナを規定するSPECなのでよさげです。P236真ん中の表は TNTという薬品？を格納するコンテナはArmored(装甲されている) ものでなくてはいけない。 という具合 -- 村井 (2010-05-12 15:21:05)
  • P236クラス図のDrumは、いわば分量だと思うのが吉かと。 Chemical(アンモニア)がDrum(１０リットル) とか -- 村井 (2010-05-12 15:22:59)
  • [些末] P236真ん中の表: Biological SamplesのSPECが Must not share container with explosives なんだけど、そういう Container Featureがあるのだろうか？ このSpecificationはisSatisfied()で Containerの中身を見て、おそらくChemicalのexplosiveフラグ(見当たらないのでそれ相当の情報)をチェックせねばならないのかとも思ったり -- 村井 (2010-05-12 15:26:38)
  • TNTは爆薬でした。 http://ja.wikipedia.org/wiki/%E3%83%88%E3%83%AA%E3%83%8B%E3%83%88%E3%83%AD%E3%83%88%E3%83%AB%E3%82%A8%E3%83%B3 -- 村井 (2010-05-12 15:34:41)
名前:
コメント:

Example:A Working Prototype of the Warehouse Packer

  • 確かにこれはひどい実装 -- kentaro714 (2010-05-11 16:28:15)
  • まぁ・・・個別のSPECを全て満たすことと、全体最適な積み方は別でしょうな。DDDというかアルゴリズムの世界なのかな -- 村井 (2010-05-12 15:47:14)
  • P240:まあSpecificationは満たしているよね。これをテストコードで書いておいたうえでいろいろ最適化を試行するのかな -- 狩野 (2010-05-26 01:38:57)
名前:
コメント:

タグ：

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

下から選んでください:

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