議事録 / 第46回

議事録

第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日(土)
• ポジペ「コミュニケーションテクニック」
  • ◎コミュニケーションテクニック
    • プロジェクト内でどうやってコミュニケーションしてるか？
    • いいツール、いい方法、失敗例
    • お客さんとコミュニケーション方法等
  • 自己啓発(次次回以降)
    • 英語とか、車のナンバー暗記とか、ジム通いとか