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

エリック・エヴァンス
翔泳社
売り上げランキング: 12,623

Amazon.co.jpで詳細を見る

実践UML 第3版オブジェクト指向分析設計と反復型開発入門