Java EE勉強会
MenuBar
編集
添付
凍結
新規
最終更新
一覧
単語検索
議事録
/
第44回
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
FrontPage
第44回 Java EE勉強会
†
日時: 2008年7月26日 13:00〜18:00
ポジペ: 「自分の定義する大規模開発」
†
都市伝説が囁かれたら大規模
ピーク時100人以上、1年以上、費用数十億
顔も知らないメンバーが居たら大規模
自分が居るところ
スケールアウト、マネージメントが必要な物
期間とか、人数
付箋で管理できるのが小規模、見たことない人が居るのが中規模、COBOLが大規模
月の売り上げの明細が400万件以上
組織間の壁があると大規模
5人×6チーム => 知らない人間が居ないから中規模
難易度も夜間バッチのみなので簡単
1000人以上(デスマではない)
はてブのネガティブコメントがたくさんついたら大規模
1年半くらいかかれば大規模
内部統制資料が必要になる場合
提案段階から気合いが入っていれば大規模
階層が深くなって5〜7階層になってくれば大規模
よくわからないグループが出てくる
日経コンピュータに出てくるキーワード(SOA, SaaSとか)が出てくれば大規模
記事に載れば大規模
これまで経験した人数よりも多ければ大規模
物理的な距離(国際協業、国籍が3〜5以上)があれば大規模
営業〜入金までの期間が長いもの
人を信じられなくなったら大規模
プログラマーを規約とかで縛り出して、軍隊っぽくなってくる
喫煙室が真っ白で見えなくなったら大規模
プロジェクトルームの向こう側が霞んで見えないと大規模
知らないプロジェクトループがあったら大規模
赤字額で1億円で大規模
ラージスケールストラクチャパターンが適用できれば大規模
1億円以上の案件が大規模
チームが複数あれば大規模
未知の世界が大規模
エンドユーザが見えなければ大規模
名刺を3〜4枚持たされたら大規模
デスマでなければ大規模でない
メインフレームなら大規模
サブシステム30以上なら大規模
EJBなら大規模
全社共通フレームワークとか使ってれば大規模
1000人月、10億円以上なら大規模
設計がごちゃごちゃしてて、破綻したら大規模
NTTデータとかがやってるのが大規模
大規模なんて怖くない
小規模の集まり
コボラーが居れば大規模
DDD
読書会 前半
†
日本でも、ユビキタス言語ではなくデータディクショナリと言う概念があった
実際に開発者とドメイン専門家が数十年イテレートして行くのは難しいのではないか
金融系では7〜年のものがありうる。
一刻も早く、法改正等に対応しなければならない。
十年越しのシステムなら普通にある。ドメインは変化し続ける。
コードの書き直しの際、ドメインモデルがあるかないかでは大きく違う
業界によってモデルの有る無しが別れてそう
金融は持ってそう。よくある業務(受発注)であれば持ってない
金融系 (特にデリバティブ系) だと、ドメインエキスパート (金融工学の専門家) の仕事の成果 (数式や Excel のシート) がしっかりしていて、そのままモデリングされる
ドメインエキスパートが確立されていると、モデリングされる → "新幹線の運行制御"など
ありがちな業務にはドメインエキスパートがいない? → 販売とか
"アプリケーションエンジニア"って人種が、OOPじゃないのはなんで?
PMとプログラマの板挟み
清書屋さん
ドメインエキスパートは、ドメインを母体としている人
IT/ソフトウェアを母体としている人ではない
言葉の定義
ドメインモデリングとドメインデザインはわかりにくい?
読みながら把握して行く
フレームワークではなく、ビジネスドメイン寄りのお話
正しいモデルはない、わかりやすいモデルがあるだけだ
TimeAndMoney
?
のドメインモデリングのフレームワーク
ドメインモデルはドメインごとに必要だが、共通化はされてもよい
階層化される。低レベル層はあってもよい
ドメインの範囲を広げれば、希釈されて共通化されていく
ドメインモデルを構成するベースパターンの一つ
スイーツ(笑)
†
DDD
読書会 Part 1 後半
†
ユビキタス言語は黒い太字になっている
オブジェクトはモデルの1表現
モデルを関数型言語で表現してもいいが、適用範囲は狭いかも
論理型言語でモデリングすれば関数型言語とマッチするかも
The objects → 前のやり取りのComponent Typeとか具体的な実装を指すのでは?
crunching → raw materialをcrunchingする
どこまでcrunchingすればいいのか?
Continuous Learning
生産性が一気に上がるブレークポイントがある
どうして「自分たちがどのくらいわかってないかを理解できない」のか
実装最中にもドキュメント等が散らばっている
イテレーション前提
分析、設計、実装ではなく、プロトタイプ作りながらモデリングするみたいな
XPの人達には当たり前のこと
XPやアジャイル前提の本である → XPしてない人には希望がないw
最初の段階で租借しておかないと、手戻りになる
実はここは手戻りの話をしている → Continuous Learningだと手戻りにならない
Continuous Learning であれば、新しい変化を Knowledge Cruncing しやすい
Chapter 10 の Supple Design で似たような話がでる
Knowledge-Rich → 業務知識が豊富に入ったデザイン
本当にドメインエキスパートで扱えるのか?
ドメインエキスパートが大事だと思うなら、モデルに入るべき
P19. に、詳細過ぎるのは推奨しない、と記述有り
お客さんにより、求められる粒度が変わる
お客さんが自分のドメインについて曖昧な部分もあるので、租借すべき
チェックをモデルの中に引きずり込む(差金決済とか)
お客さんがモデルをどういう目で見るのか、まだ書籍には出てない
クラスをクラスとして見てくれるのか。自然言語として見るのか。
語彙、モデル、正しさ → 同じ物を同じ言葉で行いましょう
きれいと正しさは両立するとは限らない
正しさよりも、ビジネスを追いかけて価値を出すことの方が大事??
ドメインモデルが重要だから
ドメインモデルに、結果としての正しさは含むのか?
モデルが間違えていれば、直せばいい
モデルと実装が乖離しないようにして、正しさを
"Knowledge crunching" = "知識バリバリ"、じゃないですw
ドメインとはどの範囲?
本書ではビジネスエンジニアリングではなく、システムエンジニアリングの範囲
システム化する範囲に着目している
3ヶ月経って、倉庫での管理業務の情報が落ちていたのは、別の問題として大きいのではないか
モデル作ったってだけで運用はしてないのでは??
運用して、knowledge crunchingしてが理想なので、運用してたのではないか
DDD
読書会 Part2
†
日本語
圏でも適用可能?
訳語表を作ることで、対応可能
日本語
で書くときは、英語
public じゃないところは、そこまで重要じゃない
ペアプロすれば揃う
難しさはあるかもしれない
ユビキタス言語には、図表も含まれる
まとめ
†
次回は2008年8月23日(P30〜)
次回ポジペ「私と英語」(時間制限厳しく!)
Problem「議論が長過ぎる」について
†
次回は、担当ごとに議論ではなく、章ごとに議論の時間を設ける。
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