Java EE勉強会
MenuBar
編集
添付
凍結
新規
最終更新
一覧
単語検索
議事録
/
第51回
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
議事録
第51回 Java EE勉強会
†
日時: 2009年02月21日(土) 13:00〜
ポジペ: 今年のトレンド予想
†
Scala
Haskell
JSの代わりがあればなあ(
NaCl
?
(Native Client)は流行らないでしょう)
Objective-C
バッチ系のフレームワーク(Hive, Apache Mahout)
Cococaをもっと評価すべき
ケータイ向けサービス、iPhone向けサービス(セカイカメラはない)
Oracle Coherence
APサーバ間でメモリ領域を共有するミドルウェア
DB要らず。全てメモリ上で可能
トルネードディスプレイ
ディスプレイが三つくっついている
Selenium
メッセージング
DDD
Silver light
Python
エンタープライズな分散
Hadoop, Google App Engine
Mule(オープンソースESB)
SimpleModeler
?
クラウド Amazon EC2/S3
github や Bitbucket
コンピュータサイエンス
Agile さっと作って納品
Simple DB
Key/ValueのDBMS → リレーショナルが重要
RIA 見た目方向のアプリ
インタラクションデザイン
Developer Test
トレンドは出ないのではないか
マネージメント側の知識
SimpleModeler
?
-> XMind -> Scala -> Groovy
Doblogがアル中向けコミュニティに
Mr.Nakagawaをイメージキャラクターに
R (言語)
DSL
(Domain Specific language)
S2
DomainModel
?
論理型言語Prolog ・・・はない
Esoteric Programming Language (Esolang)
Whitespace
Grass
Brainf*ck
「Rubyで作る奇妙なプログラミング言語」
DDD
読書会 (Chapter THIRTEEN.)
†
13章を先に行う。
Exploration Teams
†
the subject matter expertとは??
Domain Expertのこと?
Domain Expertの中でも、その問題に特化した人
"チーム"が重要視されているように思える
駄目だった時に、数日寝かすってのは面白い
上の人に、「閃かないから、名案が浮かぶまでほっときます」とは言いにくい
イテレーティブだと受け入れやすい? → イテレーティブでも、欲しい
洗練してないものはあるはず。洗練を先延ばしにするだけ。
変更を受け入れられないとなると問題になる
主力メンバーを喫茶店に連れ出すのは難しいかもしれない
欧米では、パーティションがあって職場では話しにくいのかも
ドメインエキスパートをすぐに連れ出せる??一緒に働いてるの?
XP的にはその場に居て欲しいはず
Prior Art
†
先人の知恵を勉強しておけ、と言うこと
一度お客さんの仕事をやってみるのもいいかもしれない
Timing
†
CHANGE
概念がデザインに隠れているとは?
implicitな概念をexplicitの概念にできるってこと
概念とメソッド名が一致し、クリアに見えるとよい
概念を全てクラスにすることは不可能
表面上の概念より、奥にある概念の方が抽象度は高いはず
リリースの二日前ならいいのか(笑
カットオーバーではなく、イテレーションサイクルのリリースの意味合いでしょう
Supple designの導入でドメインがおかしくなってはいけない
Crisis as Opportunity
†
ブレークスルー=「そういうこと!?」=手戻り
A period of steady refinement of a model がきっかけ
Evansが、「全部Domein Modelでやるべきではない」と言っていたようだ
「Transaction Modelでもいいんじゃないか」
どこにドメインモデルを使い、見分けるセンスが重要なのではないか
要件をまとめる人が、手続き的に書いてしまうと、コードも引っ張られる
お客さんの捉え方がCobolぽい(手続き的)。再解釈が必要。
それはそれでいいのでは?
モデリングしたほうが、いいコードになりそう
バックエンドはドメインモデリング、フロントエンドは入れポン出しポンでいいのでは
そんな単純に分けれるのであれば、みんなこんなに苦労しない
手戻り、を、ポジティブに考えているように見える
納期があるのではなく、継続開発してる人達
「そういうこと!?」→「契約を5ヶ月伸ばせるぜ!」
イテレーションしてる場合は、将来のイテレーションで楽ができる
ソフトウェアは、土台を壊して作り直しやすい
ユーザからXPでお願いしますと要求されるようになるといい
日経コンピュータで成功事例が出るのがポイント
リーン生産方式を引き合いに出す。「トヨタのやり方なんですよ」
ムダを無くす
量産行程では成功するが、新しい発明を生むのは・・・?
住宅もうまく行ってないらしい → XPを使うとしても設計部分。建築部分ではない(建築=build)
スイーツ(笑)
†
いちご大福
DDD
読書会 (Chapter TWELVE.)
†
Relating Design Patterns to The Model
†
モデルと対比させるため、設計パターンと約している
デザインパターンはドメインパターンとしても使えるが、Doing so requires a shift in emphasis(注目すべきところをシフトする)
そのまま使える物と、概念だけ使える物がある
STRATEGY
†
別名はPOLICY
STRATEGYのconsequences(GoF本)は、そのままドメインにも適用できる
Javaでenum→STRATEGY→Visitor
consequences = エッセンス、の意もありそう
COMPOSITE
†
COMPOSITEはやりすぎなのか?
デザパタ的には、入れ子の構造をきれいにするもの
ドメインパターン的には、概念的に入れ子になっているものを見つけるためCOMPOSITEを使う
階層が動的に変わるのであれば、有効。そうでないのならやりすぎ
アナパタの責任関係 の抽象度の一番高い状態に似ている??
party tettern → 個人と法人が入れ子になることはない
VISITORはドメインパターンとしては? → 使えない。テクニカルでしょう
OBSERVERはドメインパターンとして使えそう → ドメインイベント
イベント、OBSERVERはドメインに存在してよい
メモリに常に乗ってるわけではないので、実装は難しい
ブローカー経由でリスナに通知する仕組みでなんとかなるかも(Entityはメモリから消えるので)
ブローカーはドメインには必要はない。実装の話。
RDBMSのように、インフラのイメージに思える。O/Rマッパのイベント版
Why Not FLYWEIGHT
†
デザインパターンを全てをリスティングする必要はない
概念的なものに触れてるデザインパターンはドメインパターンとして使える
技術的な問題にだけ触れてる物は適用できない
デザパタをドメインパターンに使える物と使えないものに分けてみると面白いかも
★Java EEのwikiにまとめる??
DDD
読書会 (Chapter TWELVE.)
†
Relating Design Patterns to The Model
†
モデルと対比させるため、設計パターンと約している
デザインパターンはドメインパターンとしても使えるが、Doing so requires a shift in emphasis(注目すべきところをシフトする)
そのまま使える物と、概念だけ使える物がある
STRATEGY
†
別名はPOLICY
STRATEGYのconsequences(GoF本)は、そのままドメインにも適用できる
Javaでenum→STRATEGY→Visitor
consequences = エッセンス、の意もありそう
COMPOSITE
†
COMPOSITEはやりすぎなのか?
デザパタ的には、入れ子の構造をきれいにするもの
ドメインパターン的には、概念的に入れ子になっているものを見つけるためCOMPOSITEを使う
階層が動的に変わるのであれば、有効。そうでないのならやりすぎ
アナパタの責任関係 の抽象度の一番高い状態に似ている??
party tettern → 個人と法人が入れ子になることはない
VISITORはドメインパターンとしては? → 使えない。テクニカルでしょう
OBSERVERはドメインパターンとして使えそう → ドメインイベント
イベント、OBSERVERはドメインに存在してよい
メモリに常に乗ってるわけではないので、実装は難しい
ブローカー経由でリスナに通知する仕組みでなんとかなるかも(Entityはメモリから消えるので)
ブローカーはドメインには必要はない。実装の話。
RDBMSのように、インフラのイメージに思える。O/Rマッパのイベント版
Why Not FLYWEIGHT
†
デザインパターンを全てをリスティングする必要はない
概念的なものに触れてるデザインパターンはドメインパターンとして使える
技術的な問題にだけ触れてる物は適用できない
デザパタをドメインパターンに使える物と使えないものに分けてみると面白いかも
★Java EEのwikiにまとめる??
DDD
読書会 (PART IV / Chapter FOURTEEN.)
†
Strategic Design
†
大規模な構造 → アンケートによれば 50人で6 BOUNDED CONTEXT とからしい
力不足とは?
「ad hocなインタフェース でくっつけただけでは」、力不足
サブシステム化しすぎるとドメインの意味が失われる?
意味を失わない程度に
人数単位とかで分けると、危ないかも
統合データベースブーム → データベースは一つにしろ的なもの
達成できないでしょう。流行ったのは10年くらい前では?
マスタ系の統合は再び言われて来てる。MDM??MMDとか??
メッセージングによる同期であれば、ちょっと違う
サブシステムがDBをもって、メッセージングで疎結合させるのが最近の流れでは?
統合データベース厨は身を潜めてるだけかもしれない
Maintaining Model Integrity
†
不満タラタラ。吉野家コピペ的。
統合は現実的じゃない
BOUNDED CONTEXT
†
ベースがXPじゃないので、少人数でしょう
アジャイルと言っても、チームを分けるだけじゃうまく行かない気がする
コミュニケーション重視の割には、チーム間のコミュニケーションは疎になる
それでうまく行くのは、大規模じゃないからではないか
この例では、チームが初めから別れてそう
後半の例では、新しいBOUNDED CONTEXTが増えてる
DDD
の例では、意図的にパッケージ名が二つあったりする
BOUNDED CONTEXTの分け方
サブシステムとBOUNDED CONTEXTはほぼ一致?
ドメインモデルの有効範囲で分ける?
人数的な制約??
3人で開発すると3-passコンパイラができるという噂があったり
理想はドメインモデル。制約を受けるから分割せざるを得ない?
パートナーが3社ならBOUNDED CONTEXTが3個?
最初のチーム編成とその後のチーム編成が変わるとどうなるの?
→Shared Kernelとかになる?
大人数でやってはいけない
CONTEXTが違うとユビキタス言語も違う?
ユビキタス言語の方言があっていいのだろうか
近い部分では、揃えた方がいいだろう
CONTINUOUS INTEGRATION
†
概念の継続的インテグレーション、を言ってるのが新しい
実装側がインテグレーションされてれば、ユビキタスランゲージもインテグレートされそう
実装が大丈夫でも、ユビキタス言語が壊れてることはありそう
定期的なディスカッションが必要って話ではないか
実装のCIで出たエラーをきっかけに、概念側でもほころびがあるのではないか
概念のCIでは何を話すんだろうか?
「オレの顧客はこうだ!」みたいな??
概念を口頭でテスト?
業務の勉強会を継続的に
データ辞書はユビキタス言語の一部
CONTEXT MAP
†
DDD
の事例によると、CONTEXT MAPは他のパターンより圧倒的に使える
逆に言えば、これから出て来るパターンはこれより使えない・・・??
境界をどう扱うのかは出て来るの?
この後に続く6パターン(?)が、境界の扱い方を示している
次回
†
2009年3月28日(土)
ポジペ「私は○○パターン厨でした/です/になります」
次の本 ← 次回以降の
ネタ
次回は SHARED KERNELから(P.354〜) 14章 or 15章途中くらいまで
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