設計のスタイル、開発のスタイル
2017年10月21日
増田 亨
ドメイン駆動設計の基礎知識
関ジャバ ‘17 10月度 : 秋なのでDDD
本日のキーワード
型
型
アイデアをプログラミング言語で表現する手段
プログラムを組み立てる基本部品
by Stroustrup
型
• 言語に用意された型
– boolean , 整数, 浮動小数点
– 配列
• Java 標準ライブラリに用意された型
– String
– BigDecimal
– LocalDate
– List, Map
• 独自の型を定義する仕組み
– class
– interface
– enum
– (package)
型
• 値の集合 + 操作の集合
• boolean 型
– 許される値は、true false の2つだけ
– 可能な操作は、論理演算 (算術演算は不可)
• LocalDate 型
– 正しい日付 (2017年11月31日はだめ)
– 日付に特化した演算
• isAfter(), isBefore()
• plusDays(), minusDays(), …
• until(), …
プログラミングの2つのスタイル
• 型の利用者
– 言語の組み込み型を使う
– 標準ライブラリの型を使う
– 誰かが作ってくれたユーザ定義型を使う
• 型の生産者
– 基本データ型を使って独自の型を定義する
– 独自の型を組み合わせて、さらに型を定義する
オブジェクト指向のアンチパターン
基本データ型への執着
長いメソッド
大きなクラス
たくさんの引数
コードの重複
変更の分散
…
出典:リファクタリング 不吉な臭い
オブジェクト指向のアンチパターン
基本データ型への執着
長いメソッド
大きなクラス
たくさんの引数
コードの重複
変更の分散
…
諸悪の根源!
「基本データ型への執着」が他の症状を誘発する
オブジェクト指向 良い習慣
基本型をラップして、独自の型を定義する
(値オブジェクト)
コレクションをラップして、独自の型を定義する
(コレクションオブジェクト)
区分を列挙して、独自の型を定義する
(区分オブジェクト)
基本データ型より
独自の型が良い理由
基本データ型より
独自の型が良い理由
正しさ
表現力
Find Usage
正しさ
• 基本データ型
– 値の範囲が広い
– 可能な操作が汎用的
– 特定の目的のためには、まちがった範囲、まちがっ
た操作を含んでいる
• ユーザ定義型
– 値の範囲を用途に合わせて制限する
– 可能な操作を用途に合わせて限定する
– まちがいが減る
– 安全・安心
表現力(ドキュメント性の向上)
• 基本データ型
– いろいろな用途に同じ型を使う
– 10種類くらいの単語(型)だけで、なんでもかんでも
説明されても意味がわからない
• ユーザ定義型
– 用途が具体的で明確な型(語彙)が増える
– 引数の型、メソッドの型、シンプルなメソッド名
– 「型」をレビューすれば、コード内容を推測できる
(わかっているか、勘違いしているか)
ソースコードのレビューでなく、プロジェクトブラウザとdiagramでの型のレビュー
powered by IntelliJ IDEA
Find Usage
• 修正や拡張をする時に、影響範囲を的確に
判定できる
– コンパイラーによる型の整合性の検査
– IDE による型の整合性の検査
– Find Usage コマンドでのブラウジング
– リファクタリング preview
• 「型」はリファクタリング=設計改善の
最強ツール
powered by IntelliJ IDEA
ポリモーフィズム
(型の多相化)
良い単純化、良い部品化に
役に立つ仕組み
ポリモーフィズム(多相、多態)
• (暗黙的な)型変換
– long + int , “value:” + int , …
– int <-> Integer
• オーバーロード
– BigDecimal( int ), BigDecimal( String ) , BigDecimal( BigInteger), …
– 型変換の責任を使う側から、使われるクラスに移動する
• 型のパラメータ化(ジェネリクス)
– List<T>
– さまざまな型に利用可能な原型を提供する
• 部分型(subtyping)
– interface宣言, enum 宣言
– 型のグルーピング:同じグループの型を、同一の型として利用する仕組み
どの仕組みも、とても便利
しかし、中途半端な使い方は事故の元
上手に使うのが設計の腕の見せ所
設計のスタイルの分類
• モジュール化
– 型(データ+操作)に分解するか、
手続き(サブルーチン)に分解するか
• 独自の型
– 積極的に独自の型を定義するか、
できるだけ基本データ型でがんばるか
• 型の記述
– 明示的に書くか、型推論に頼るか、
できるだけ暗黙にするか(型を書かない/書けない)
• 型の検査
– 設計中(IDE)、実行前(静的)、実行時(動的)
ドメイン駆動設計の開発スタイル
ドメイン駆動設計
• ドメイン(問題領域)に特化した型の探求活動
• 良い型は、最初からは見つからない
• 実験的に探究する
良い型は最初からは見つからない
• 問題領域の知識が不足している
• 問題領域を深く分析できていない
• 型でビジネスロジックを表現する設計パター
ンの知識不足/経験不足
• 初期の型の使い勝手の悪さ
• 型の成長性(変更容易性)
実験的に探究し進化させる
• 型のアイデアの発見
– 雑談、ラフスケッチ、…
• 型のアイデアをコードで書いて試してみる
– だめなら捨てる
– いけそうなら改善を続ける
• もやもやしたら別のアイデアを試してみる
– 新たな発見 and/or 元のアイデアの再評価
• 小さなステップの繰り返し
– アイデアだし、実験、改善に done はない
– タイムボックスで先に進む
ドメイン(問題領域)に特化した
ユーザ定義型の見つけ方
ドメイン特化のユーザ定義型
4つの見つけ方
問題領域から
型の振る舞いの設計パターンから
プログラミング言語の汎用の基本型から
過去の経験から
4つの方向からのアプローチを組み合わせる
いったりきたりする
ドメインに特化した
ユーザ定義型
ユビキタス言語
業務の用語
画面
業務マニュアル
汎用の基本型の
用途を限定
値の範囲
メソッドの型
メソッドの名前
既存のアイデアの流用/カストマイズ
過去に経験したシステムの設計内容
分析パターン/ビジネスパターン
データモデリングのパターンカタログ
型の振る舞いの設計パターン
判定(同値、大小、最大/最小)
加工(型変換、短縮形、合成)
計算(四則演算)
型
アイデアをプログラミング言語で表現する手段
プログラムを組み立てる基本部品
正しい値と正しい操作の集合
ちょっとディープな参考資料
• 型をプログラミングの基本部品とする考え方
– Liskov, Strastrup, Meyer の系譜
• 実験的な開発スタイルを重視する考え方
– Alan Kay の系譜
– Dahl, Liskov, Meyer も、オブジェクト指向アプロー
チの動機の一つとして、プログラムをボトムアップ
で実験的に組み立てていくアプローチに言及して
いる
1. Java SE Specifications --- 4.2 Primitive Types, 4.10 Subtyping
– https://docs.oracle.com/javase/specs/jls/se9/html/index.html
2. 書籍「型システム入門」 第1章 はじめに
– http://www.ohmsha.co.jp/data/link/978-4-274-06911-6/types-and-
programming-languages-ja_p1_0-ch01.pdf
3. History of CLU by Liskov
– http://publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TR-561.pdf
4. What is Object Oriented Programming by Straustrup
– http://www.stroustrup.com/whatis.pdf
5. オブジェクト指向入門 by バートランドメイヤー
6. The Early History of Smalltalk by Alan Kay
– http://worrydream.com/EarlyHistoryOfSmalltalk/
7. Structured Programming by Dijkstra, Hoare, Dahl
– https://dl.acm.org/citation.cfm?id=1243380
8. SIMULA by Dahl, Myhrhaug, Nygaard
– http://web.eah-jena.de/~kleine/history/languages/Simula-
CommonBaseLanguage.pdf
無料サンプル
有料
3,4,5 は抽象データ型派、6 はアンチ抽象データ型、
7 は三者三様、8はオブジェクト指向の原点の一つ
実験的なアプローチは、6 に詳しい。 3,5,7,8 もボトムアップで実験的なやり方を重視

ドメイン駆動設計の基礎知識:設計のスタイル、開発のスタイル