Java EE勉強会
MenuBar
編集
添付
凍結
新規
最終更新
一覧
単語検索
議事録
/
第48回
Menu
Top
JavaEE勉強会
参加するには
FAQ
MakingSenseofStreamProcessing
MicroservicesVsSOA
ModernJavaEEDesignPatterns
BSA
EIP
DSL
DDD
議事録
最新の20件
2023-11-24
MicroservicesVsSOA/The World of Service-Based Architectures
2020-11-14
DDD/Knowledge-Rich Design
MakingSenseofStreamProcessing/Example Implementing Twitter
2020-10-28
EIP/Aggregator
2019-12-18
EIP/Publish-Subscribe Channel
2018-06-10
FrontPage
2017-07-08
MakingSenseofStreamProcessing/Materialized Views Self-Updating Caches
MakingSenseofStreamProcessing/Summary Four Database-Related Ideas
MakingSenseofStreamProcessing/The Unbundled Database
MakingSenseofStreamProcessing/Conclusion
MakingSenseofStreamProcessing/Streaming All the Way to the User Interface
MakingSenseofStreamProcessing/4. Materialized Views
2017-06-11
MakingSenseofStreamProcessing/1. Replication
MakingSenseofStreamProcessing/Bringing the Unix Philosophy to the Twenty-First Century
MakingSenseofStreamProcessing/2. Secondary Indexes
MakingSenseofStreamProcessing/3. Caching
MakingSenseofStreamProcessing/How Databases Are Used
MakingSenseofStreamProcessing/Composability Requires a Uniform Interface
2017-03-25
MakingSenseofStreamProcessing/Unix Architecture versus Database Architecture
MakingSenseofStreamProcessing/Turning the Database Inside Out
議事録
第48回 Java EE勉強会
†
日時: 2008年11月29日(土) 13:00〜
ポジペ: 「自己啓発」(技術系以外で)
†
podキャスト(English as a second language.)
料理
睡眠時間を
洋書を読む
DDR
朝のウォーキング
人に薦められたものを断らない
ジョギング
散歩
英語のシャドーイング
映像記憶 : 詰め将棋
脳トレ
フォトリーディング
レーシックの資金集め : 自分への罰金制度
英語で書き込み
λ計算、圏論
Project Euler
東大のpodcat
DDD
読書会 (Chapter SEVEN.)の議論
†
REPOSITORIESはDAOと変わらない
Handling EventはENTITIES??
時系列で言えば、一意性は必要
「イベント」はエンティティじゃないかもしれないけど、記録すればエンティティでしょう
Fowler的には、ログでしょう
Handling Eventのtypeがenum
新しい構成要素と思われる"Domain Event"に関しての情報は?
MLやフォーラムだと埋まっちゃう。どこかにまとまってないかなあ。
循環参照を、実装で解決していいの??
RDB的には、相互参照ではない(外部キーによる一方向の参照)
本の例は汎用的ではなさそう
概念の段階では循環参照は問題ではない、と言うのがこの本の主張
サンプルではHibrenateで解決・・・
AGREGATE境界内に検索が必要な場合にどうするの?
AGREGATEは絶対重なりそう
AGREGATEはライフサイクルを見るためのツールなので、重なるとまずい→COMPOSIT的?
AGREAGTEが重なる=モデルがおかしい=モデルを直す瞬間、では
AGREGATEは、P.134のように明らかに一体となってる場合のみに使うのでは
AGREGATEは大したことない、説(佐藤さん)
DDD
のサンプルはどうなのか
入れポン出しポンぽい
DDD
のサンプルとしては拍子抜け
DDD
ってことを考えなければ、普通にできそう
Handlig EventはAGREGATEに属さず、REPOSITORYもない。なんで?
ライフサイクルが違うから、AGREGATEには属さないでしょう
P169で循環参照について触れているとこで、後でRepositoryが登場するだろうことは書かれている
P172の段階では、Handling Eventを誰が永続化するのかは決まってないのでは?
Handling Eventを永続化すると言うユースケースがないから、まだ不要なのでは
グローバルアクセスが必要だと、REPOSITORYは必要
P171によると、Handling Eventは low-contention transaction で作られるためAGGREGATEに入れない
Handling Eventは、AGGREGATEのrootなので自由に呼んでいい
ライフサイクルを示すだけなら、AGGREGATEはUMLのcompositionで十分では
P128的には、黒塗りの集約(composit)ではない ←単に黒塗りは使ってないだけ??
ユースケースによってAGGREGATE境界は変わりそう
↑リファクタリングと洞察が足りないのでよくわからないのでしょう(笑)
P174. we still have to have a primitive constructor の真意は?
言語使用的なのか、
DDD
的なのか
Java的には protect とかにしたいよね
親クラスが子クラスを返すのは気持ち悪い?
enumの実装は、これをやってる。気持ち悪くないでしょう
サブクラス名が親クラスにあるのは気持ち悪い。定義ファイルとかあればなあ。
今後絶対増えないサブクラスなら、問題ない。enumでは、コンパイル時に確定して変化しないから
Analysis Patterns の Enterprise Segment の説明が欲しい
長くなり過ぎる。省略。
Analysis Patternsは役に立つかは別として面白い(koichikさん談)
スイーツ(笑)
†
醤油とあんこのお団子
DDD
読書会 (Chapter EIGHT.)
†
今回はプロジェクタがないので、一つずつ議論しつつ進める。
Refactoring Toward Deeper Insignt
†
"why it does what it does"を表すコードとは?
コードでwhyは無理でしょう
コードで表す必要はなく、なんでそうするか理解できるようにする
モデルが洗練されていると、直感的にwhyがわかるのでしょう(best effort的)
toとtowardの違い
英語的には、toは目的地に着く。towardは向かっているだけ
Deep Model-Supple Design
†
P.50に、フィードバックループの図がある
Breakthrough
†
ブレークスルーが起きないこともあるのでは
不要だったと考えるしか
細かいりファクタリングを積み重ねるしかない
頭打ちが来た時がチャンス
日本の文化的にはブレークスルーは訪れない方が平和・・・
Story of a Breakthrough
†
向こうのBOSSはこんなにいい人ばかり?
思い浮かんだブレークスルーが失敗だったらどうするんでしょう?
コード管理してれば、巻き戻せるはず
ビジネスエキスパートと話が合う合わないと言う点では、明らかに新しいモデルの方が優れている
イテレーションが小さいので、見通せるのだろう
実話?? → 実話ベースっぽい
ブレークスルーと規模は関係ないでしょう
A Cascade of New Insights
†
ドメインエキスパートも使わないような新しい言葉が産まれてくるのか??
ドメインエキスパートがわからない言葉はNGでしょう
むしろ、普段流していた言葉に、重要だと気がつくことでしょう
P212 favorite domain expert
DDD
読書会 (Chapter NINE.)
†
Digging Out Concepts
†
英単語は変わっているが、ここで出た5つの点について今後各節で掘り下げている
Listen to Language
†
専門家の「it is normal(普通)」は開発者の言ってるnormarized(正規化)を勘違いしたものでしょう
この話、実際はないでしょう
開発者が暴走し過ぎ
ドメインエキスパートが我慢強い
開発者の遠慮がなさ過ぎ(開発より)。これがユビキタスランゲージ?
Scrutinize Awkwardness
†
開発者が自ら気がついてリファクタリング
「運」が2回入ってる → 運が重要なんでしょう
'Hard Way'な例なの??
ドメインエキスパートにはHard Way?
Earning Interest は掛詞?
'By the Book'の方が楽?
専門家に聞いた方が楽では
他で使えない業務知識の本を読んで覚えてもなあ
原発制御とか、本もないだろうなあ
Try, Try Again
†
一発成功を目指すSIerでは無理でしょう
話の分かる上司が必要
上司は盾か壁か
お客さんの強力があれば
検証フェーズだけなら
本読め、try again、ブレークスルーを目指せ
モデリングの本ではない?
ビジネスモデリングの本ではない
DDD
は、ドメインで駆動される"設計"の本であって、ドメインの本でもドメイン設計の本でもない(DESIGNがタイトルで一番でかい)
次回
†
2008年12月20日(土)
ポジペ「振り返りを
KPT
方式で」
次回はCHAPTER9のP219からCHAPTER10
Menu
Top
JavaEE勉強会
参加するには
FAQ
MakingSenseofStreamProcessing
MicroservicesVsSOA
ModernJavaEEDesignPatterns
BSA
EIP
DSL
DDD
議事録
最新の20件
2023-11-24
MicroservicesVsSOA/The World of Service-Based Architectures
2020-11-14
DDD/Knowledge-Rich Design
MakingSenseofStreamProcessing/Example Implementing Twitter
2020-10-28
EIP/Aggregator
2019-12-18
EIP/Publish-Subscribe Channel
2018-06-10
FrontPage
2017-07-08
MakingSenseofStreamProcessing/Materialized Views Self-Updating Caches
MakingSenseofStreamProcessing/Summary Four Database-Related Ideas
MakingSenseofStreamProcessing/The Unbundled Database
MakingSenseofStreamProcessing/Conclusion
MakingSenseofStreamProcessing/Streaming All the Way to the User Interface
MakingSenseofStreamProcessing/4. Materialized Views
2017-06-11
MakingSenseofStreamProcessing/1. Replication
MakingSenseofStreamProcessing/Bringing the Unix Philosophy to the Twenty-First Century
MakingSenseofStreamProcessing/2. Secondary Indexes
MakingSenseofStreamProcessing/3. Caching
MakingSenseofStreamProcessing/How Databases Are Used
MakingSenseofStreamProcessing/Composability Requires a Uniform Interface
2017-03-25
MakingSenseofStreamProcessing/Unix Architecture versus Database Architecture
MakingSenseofStreamProcessing/Turning the Database Inside Out