Java EE勉強会
MenuBar
編集
添付
凍結
新規
最終更新
一覧
単語検索
議事録
/
第46回
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
議事録
第46回 Java EE勉強会
†
日時: 2008年9月27日(土) 13:20〜18:00
ポジペ: 「ドキュメントの書き方」
†
一通りは書いたが、お客さんのため
自分 or チームメンバーのため
wikiに書く(こんふるーえんす?)
→
http://www.atlassian.jp/software/confluence/
設計は後で書く → まとめサイトのようなイメージ
設計は変わる
Bugzillaベース
if文までの詳細を記述 → 「赤い柱」事件
全体が見れること、論理が終えること
概念モデル、業務フロー、要求しよう、画面仕様、テーブル定義、テスト仕様
図・サンプルドリブン(具体例から)
ソースとの同期 → 自動生成がのぞましい
モジュール一覧、クラス図など を、後付け
図で表現。字をなるべく書かないようにしたい
Power Pointで画面遷移 → ドキュメントが置いてかれる → 役に立たなくなる
コメント + 動く物、が望ましい。フロントエンドのドキュメント
ドキュメント(成果物)は「書かない」と明言してる
お客さんの考えをまとめる手伝いをする。ドキュメントはお客さんが書く。
お客さんに考えてもらった方がうまくいく。
コンサルの立場の時はドキュメントの書き方のアドバイスをしている
誰のためのドキュメントなのか? が大事
事前レビューのツールとして利用
読み手と用途。また、読み手に何を求めるのか
行動?フィードバック?理解?
インプット、処理内容、アウトプット
過去のPJの
雛形
。0から作らない。
Alt+Pでハードコピーをなるべく取る
ドキュメントが足りない。ドキュメント重要。
プログラムがなくても、プログラムがわかるドキュメント。プログラムがわからない人も読めるから良い。
詳細設計にSQLを書いて、ドキュメントにする
なんでもExcel(XMLを全てExcelで) → ほんとに意味あるのか
実装を考慮してないドキュメント → 実装がドキュメントに引きずられてひどい状態に
詳細設計はあまり書かない → プログラマはドキュメントで概要を知り、ソースを見るはず
「現行踏襲」 ← COBOLからWEBにするのにどうするの?
ドキュメントから設計者がイメージできるか、設計者に聞く
日本語
で詳細設計 → 英語の名前をバインディング
入力、処理、出力、を
日本語
で。クラスのメソッド単位
IBM仕様らしい
ドキュメントが、どの部分(どの層?)を書いた物なのか、がわからない
層をきちんとわけると、全体が見えない
難しい
DDD
読書会 (Chapter Four.)
†
「強調する点が異なっている」→「」
責務駆動? 責任駆動? → 責務駆動って訳されてる?
DbC(Design by Contract) は? → 準拠
「オブジェクト指向入門(Object-Oriented Software Construction)」の中でDbCは出てくる
フレームワークにアプリケーションが引きずられる
最近は、フレームワークはサポートになっているので、そう言うことは少ないはず(POJOとか)
最近は「依存しな過ぎ」かも。型チェック等の利点を考えると、適度に依存した方がいい(POJO信仰)
恐らく、POJOじゃないものを作っても使われない。POJO信仰に沿うしかない
分け過ぎると、薄過ぎる層の意味のないクラスができる
User Interface と Application を 一緒に Presentation 層と言うパターンもある
Persistenceレイヤは?(DAOとか) → Infrastructureに入る? DAOはなくなりつつある。
Infrastructure層に
EntityManager
?
を DI すれば、DAO層は要らない
Transactionスクリプトのパターンが日本では多い(Action - Service - DAO)
Application層は、Domain層を制御する
DDD
的には、オブジェクトじゃない物はService
Fowler的には、サービス層はドメイン層?
ドメイン層からは分離されてたのでは?
Fowlerのサービス層が、
DDD
のApplication層
ServiceはFacadeに近い
ドメインのモデルを、ERモデルで実装してもよい?
ERモデルとドメインモデルを一致させる(Simple Domain Model)
または、別物にして、O/Rマッパが頑張る(Rich Domain Model)
RoR で
ActiveRecord
にロジックを書く?
コントローラに全て書いたけど、イマイチ
複数Entityにまたがるものは、インスタンスメソッドにしにくい → 静的関数の利用
DB をドメイン層と言って、Viewにバインドしてもいいの?
それはドメイン層はない → Smart UIになるでしょう
ERモデルの方が、技術に依存しないので、融通が利く。
Javaの世界でも、Simple Domain Modelに流れている気がする。O/Rマッパに頑張らせすぎない
O/Rマッパとドメインモデルの乖離は、自動化の妨げになる
ドメインモデル は、データモデルじゃない。ロジックを持つべき
ドメインの「概念」がドメインモデルに入っていれば、EntityでもServiceでも関数でもいいのでは
TRANSACTION SCRIPT は Smart UI と LAYERED ARCHITECTURE の中間?
P79の上部に書かれている
もう一冊(ドメイン駆動,.NET・C#の本)の方には、たくさんレイヤを分割するのにはこだわってない
UI〜Application は、そこまでこだわらない
Infrastructureは分けたい
分け過ぎは無駄なクラス
今日のスイーツ(笑)
†
ふくさ餅
DDD
読書会 (Chapter Five.) - その1(P103まで)
†
関連を「限定」する
限定するのは難しいと思われる
間接的にクエリで取って来れる関連は書かない
関連を辿ってできる関連は書かない
rootとそれぞれがやりとり、それぞれ同士は直接やりとりしない
ODB的な考え
関連の限定は、実装を意識しているんだろう
段階的でもいいかもしれない。実装して、不要なら取り除き、とか。
モデル上から関連を外すのか、実装でだけ外すのかは重要
モデリングのレベルで、重要性を加味して取り除くのでは?
辿れるから、ではなく、プロジェクトでは使わないから、外す
考えてるだけでは、本質的かわからない。動かしてみるのが大事
多-多 は、1-many と many-1 にして、中間Entityの概念を入れた方がいい
中間Entityは、意味があることがおおいので、Entityとして抽出すべき
Country と Person が 片方向でいいのは、恐らく president だから
経験上、双方向で残す関連が多い → 実装時に、決断する?
DDD
的には、実装で片方向にするのなら、モデルも片方向になるが・・・
モデルは頭の中。ドキュメントを直す必要があるとは限らない
パフォーマンスが悪化することがないから、削らない
関連のメンテって大変では??
関連はForeign key だから双方向
Serviceのレイヤで吸収できる
DDD
的には、ドメイン知識を深めると、自然と単方向に変わるってのが重要では
単方向で始め、必要になったら双方向というアプローチもいいかもしれない
Foreign key を持ってる側からの単方向は原則ある。逆方向は必要に応じて。(ERモデルがあれば、こう)
先にあるオブジェクトに向く。配達→注文(ERモデルがなければこう)
Entityに対しては、idを定義しなければならない
Javaだとhash()も
super クラスで定義してもいいかも
Entities と Value Object のドキュメント化は?
ステレオタイプ等でクラス図に記述
ドメインモデルにはEntity までしか登場しない → VALUE OBJECTは、属性として登場する
重用するのはドキュメント化よりも、関わる人が区別すること
window styleは、Entityでは?
人気のスタイルなどがあって、名前がつけばEntity
VALUE OBJECTの利点は?
不変性 → Fowlerは不変性を求めているが、
DDD
的には不変じゃなくていい(P101の欄外)
IDが不要
Entity と VALUE OBJECTの違いは?
Entity はequals() できるのが必須。VALUE OBJECTは必須じゃない
Fowler と Evansの定義が違う。Evansの定義はゆるい。
DDD
内のVALUE OBJECTは、DTO等と呼んだ方が世間とのズレは少ないでしょう
Entity と VALUE OBJECT と Dataの入れ物がある?
Dataの入れ物 → 引数オブジェクト、みたいなもの
住所は、Entity でも VALUE OBJECT でもない気がする
Dataの入れ物、のように意味のない物があるのは何か違和感が。実装テクニック?
意味のある物に昇華する可能性がある。まとまるものはまとめておいた方がいい
現実的には、元となる概念をしっかり知っていれば、区別はそこまで重要じゃない
おまけ1
†
koichikさんのメール2通拝見
DDD
読書会 (Chapter Five.) - その2(P109-P116)
†
フレームワークのちょっとの矛盾で崩壊する
DDD
はナイーブ過ぎる。現場で使えない。
実際は、Domainの概念ではなくInfrastructure でパッケージを分けてることが多い
Serviceを概念で分けることは見たことある
entity.*の直下にフラットなことが多い
entity以下を切ってるプロジェクトもある。ただ、その上にレイヤのパッケージも切っている
パッケージングで、概念が先かレイヤが先か
プレゼン層はユースケースで分けるとすっきりする
チームごとにパッケージを分けている → まとめやすいから
概念が先なら、その下でレイヤで切る
サブシステムごとにドメインも別なので、サブシステムで切る
DDD
ではコミュニケーションが大切 → コミュニケーション取れる範囲で
DDD
を実践する
最終的なパッケージの理想型の話は、出て来ない
※ 次回は、
SERVICES
, Modeling Paradigms
おまけ2
†
koichikさんのポジペ拝見
次回
†
2008年10月25日(土)
ポジペ「コミュニケーションテクニック」
◎コミュニケーションテクニック
プロジェクト内でどうやってコミュニケーションしてるか?
いいツール、いい方法、失敗例
お客さんとコミュニケーション方法等
自己啓発(次次回以降)
英語とか、車のナンバー暗記とか、ジム通いとか
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