java-ja.DDD にいってきました
java-ja.DDD に参加して来ました。
- 会場を提供してくれた GREE さんすごい。ビールとピザとオードブルごちそうさまでした。
- 補欠で参加登録したけど、繰り上がりで参加できた。
正直、「エリック・エヴァンスのドメイン駆動設計」 を買ったがパラパラとめくっただけでまだ全文を読んだとは言えない状態な自分。
今回、参加して DDD とはどういうことか自分なりにまとめると
- ソフトウェアが複雑なのではない。複雑なユーザーの行動・ビジネス要件をシンプルに定義できないから複雑なソフトウェアになる。
- データ構造も重要だが、ユーザーがどのようにシステムを触るかという観点(ストーリー)に沿ってモデルを考えてみる
- モデルに対して機能を付与したり組み合わせる。処理をそのモデルに任せる。
- 汎用的な名前をつけるよりも、具体性をもった名前をつけて特化した意味をモデルに対してもたせる
- ドメインエキスパート: 業務を定義する人
- ドメインエキスパートという人物、役割の人と協力してシステムを構築することが大事。ドメインエキスパートは一人ではないこともある。いなければ自分がなるしかない。あの業務ならあの人かなーっと想像しながら説明を聞いていた。
- 作ろうとしているシステムにもよるがエンジニアがやるのはアリな気がする。
- 命名大事
はじめての java-ja 勉強会参加したが、よくある勉強会と違ってプレゼンの途中でもガンガン質問が飛んでくる。議論が深まっていくのが面白いですね。なるほど時間を長めにとるわけだ。
「ブログ書くまでが java-ja だからね」
以下、メモを記録として載せておきます。# 僕の感想よりもメモのほうが重要な内容だと思うよ。
DDD入門
和智さん
グロースエクスパートナーズ
id:digitalsoul
@digitalsoul0124
ざっくり DDD 入門！！ from Yukei Wachi
ソフトウェアは複雑か?
複雑なのはユーザの行動 ・ ビジネス
業務知識をソフトウェアに落としこむ
- データ構造
- 演算
- ルール
- システム間連携
自分の書いたコードがどこで利用されるのか理解している?
- 「このコードが何を意味するのかわかるとき 」-> 結合テストをすると
- ↑怖いね。
業務知識を反映しないソフトウェアの構造
- トランザクションスクリプト
- 処理内容に関わらず構造は安定している
- 大事なコード(大事な制約)が埋もれる可能性
- 設計書に書かれてもコード自身が埋もれているので気づかない
- 大事なことをわかりやすいところに書こう → モデル
- 制約をコード内で可視化する
- あとでみても気づく
モデル駆動開発
- 複雑なドメインの設計はモデルを使用する
whirlpool
うずまき: http://domainlanguage.com/ddd/whirlpool/
- シナリオを作る(ユースケース・フィーチャー)(Scenario)
- Model を定義する(Model)
- コードを書いてみる(code probe)
probe : 徹底的に調べる
ソフトウェアのモデル
- 作るべきは業務のモデル
- シンプルなら E-R図
- ルール・演算をモデルにする
- オブジェクトの設計
[ドメイン駆動設計の実践] リッチなドメインモデル名前探しの旅
有限会社 システム設計
増田 さん
スライドがslideshareに公開されていました。
リッチなドメインモデル 名前探し from 増田 亨
ドメイン駆動開発
オブジェクト指向 基礎訓練 ThoughtWorks アンソロジー エクササイズ・9つのルール・小さく作る
設計の改善
設計のスタイル - オブジェクトデザイン 責任駆動設計 役割ステレオタイプ - 実践UML - オブジェクト指向入門 原則・コンセプト
ドメイン駆動設計への道
大きな泥団子
-
- リッチなドメインモデル
- 業務の言葉で組み立てる
- 小さなオブジェクト
- 役割を単純に
- ばらばらにしてシンプルにしよう
- リッチなドメインモデル
ドメインモデルの開発
小さな要件をくり返し回す。
- 名前探しの旅
プログラミングは名前探し
- 名前に手を抜く -> ひどい設計になる
- 名前付けを業務の言葉で埋め尽くす
「ドメインエキスパートなんていやしませんよ。自分より業務に詳しい人はいる」
業務の言葉をオブジェクトで
いろんな言葉(営業日、休前日日、日付、金額、製造番号、季節料金ほげほげ)
プログラミング言語の基本データ型をラップして業務の基本用語ごとのオブジェクトにその業務用語に関するデータとロジックをまとめる
超重要: ファンダメンタルなオブジェクト
トランザクションスクリプトが利用する、業務用のオブジェクトを作りこむほど楽になる。
- 業務オブジェクトに仕事を任せる
- 細かいルールが業務に散りばめられている
- コードの共通化と業務の共通化は違うので注意してほしい。
- コードは共通化しても業務自体が別なものであると副作用がおきる
超重要
- 良い名前
- 小さく作る
- ばらばらいんする
良い名前の見つけ方
- 語彙を増やす
- 読む 調べる 聴く 尋ねる
- 名前の宝庫は調べる（読む 調べる） その分野のガイドブック 専門書はかったるい 類似サービスのヘルプ画面 カタログ
- プロジェクトアサインの初日に海外版を調べてみる = クラス名の宝庫
- exp: EC サイトなら Amazon のヘルプ
- 聴く 尋ねるをすることでその人の関心度を調べる
- 正しく使う
- 言葉を使って相手の反応をみる
- 言葉を組み合わせて反応をみる
- 似た言葉を使い分けて反応をみる
小さく作る
- クラス: 50行以内
- メソッド: 3行以内 -> 厳しい
- パッケージ: 10ファイル以内
この条件を超えたら分割を考える習慣をつけたほうが良い
テストをしないといけないほど不安なオブジェクトのコードは書いていない。組み合わせた場合のテストは書く。
ドメインモデルで try catch はおかしい。なぜ例外が発生する?そこを考えたほうが良い。
騙されたと思ってやって欲しい。
how より What
expireDate.add(-1)
↓
expireDate.previousDay();
↓
expiåreDate.dayOfFinalAlert(); <- 業務の言葉の登場
汎用部品を専用部品に
- String とかをラッピングして具体的な名前に
- 目的に特化した言葉
- 業務固有の言葉
- 再利用することは考えてない
if を使わない
enum
starategy
Missing Object パターン（null object）
Map, Set
java なら enum が強力(タイプごとに異なる振る舞いをどこでも if 文なしで記述)
Bean Validator
if 文を消す場合に チェック - 範囲 - 必須 - 形式
Assert 契約による設計
assert date != null : "有効な日付のみ"
for を使わない
ファーストコレクション - コレクション操作ロジックの置き場所
collection フレームワーク API の復習(TreeMap, Deque)
ひと手間かければ for if いらないよ。
- Comparable の実装
- Comparator の実装
- equals() / hashCode() の override
setter を使わない
完全コンストラクタ - value Object パターン - 生成時に必要な値をすべてセット - new Money(amount, currency,…..);
getter を使わない
@Deprecated - フレームワークは作ってもいいが、アプリケーションでは使ったらだめよ
get したいときは役割分担がおかしい - get して何かするおではなく、何かしてもらったほうが良いのでは? - ロジックの移動(データにロジックを寄せる) - フィールドの移動（フィールドにデータを寄せる）
構造の変化に備える習慣
構造は安易にコードに埋め込まない。初期の構造は間違っていることが多い。 構造の変更を簡単にする準備をしておく。
移譲メソッド:面倒でも隣人とだけ話す
☓ person.contactInfo().phones().mobile()
○ person.primaryContact()
実装継承
パッケージ階層: フラットに
パッケージスコープを好む
public 宣言は控えめに(もっと控えめに)
import 文少なく。もっと少なく。
- クラスの分割が必要なのでは?
- パッケージの依存関係の改善の余地
実装に関してはJavaの話。適宜自分が使っている言語に置き換えてね。
CPUパワーも潤沢だし、メモリもあるし、VMも優秀だし小さくクラスを作ってもオーバーヘッドは問題なるほどないんじゃないかな。 問題がある場合はチューニングしよう。
LT Memo
エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)
posted with amazlet at 13.03.24
実践UML 第3版 オブジェクト指向分析設計と反復型開発入門
posted with amazlet at 13.03.24
クレーグ・ラーマン
ピアソンエデュケーション
売り上げランキング: 76,439
ピアソンエデュケーション
売り上げランキング: 76,439
