エリックのDDD本を読んで30分で挫折した僕が考える、こーゆーことをやるのがドメイン駆動設計なるものなんじゃないの、という資料です。

1. これって、ドメイン駆動設計？
YUMOTO Michitaka
@gothedistance

2. ドメイン駆動設計がよくわからない
ソフトウエアを利用する人たちの活動と関心事。
ドメイン
大量の情報を要約した、本質的でシンプルなもの。
モデル
ユーザーの活動と関心事から導かれたモデルを用いて実装
を行ない、ドメインの進化をソフトウエアが包括的な秩序
を与えることで、より良い活動を推進(駆動)しうるための
設計手法・・・という所までなんとなくわかった。
まとめると…
2

3. いくら話を聞いても分かりそうもねぇ
絶対的な定義など無いことは、まぁわかる。
3
我流でも何でもいいから、これがドメインであって、
これがモデルであるとまず仮決めしようと思った。
弊社の社内システムの開発事例をドメイン駆動設計
で使う言葉を使って説明することで、なんとな∼く
の輪郭をつかめるのではないかと。
ただ、明確な線を引くことは絶対に必要だ。
僕が内製したシステムの設計を中心にどんな感じで
進化したのか、その時に何を考えたのかについて、
書いていきます。

4. 弊社概略
雑貨の製造・卸売販売業をしています。
4
社長、営業マン、営業事務、経理、倉庫管理者、
商品企画、僕、その他パートという人員構成。
弊社の社内システムを振り返るとサポートする仕事
が拡大してました。フェーズに分けて振り返りたい
と思います。
オリジナル商品を作って販売すること、他社の雑貨を
卸して販売する。この２本立てがコアドメイン。

5. 5
Phase One

6. フェーズ1. 受注→出荷
東日本大震災で近隣倉庫が廃業した。
6
近隣倉庫は車で10分だったが、滋賀県の彦根市は
400kmも東京から離れている。
顧客の注文を処理する人とそれを出荷する人が完全
に分業されたことで、その間のコミュニケーション
を取り持って出荷できるようにする必要があった。
関東はアカンから、滋賀県の彦根市に倉庫を構えた。

7. フェーズ1. ドメイン(仕事内容)
7
注文書
受注
入力
出荷
FAX
出荷指示
出荷
本伝
入力
出荷連絡
本社 倉庫
フェーズ１の業務フロー

8. フェーズ1. ドメインの補足
顧客から注文書を主にFAXで頂戴する。
8
入力通知を受け、倉庫担当者が商品をピッキングして、
出荷明細書を印刷し、商品を出荷する。
本社は出荷した内容を元に本伝票(納品伝票)を切る。
当時はリースを組んだ販売管理のシステムによって
月締めの請求書を発行していた。
本社の人間が倉庫にある商材のみ、受注入力する。
出荷時に結果報告を望む顧客に限り、ReFAXをする。

9. フェーズ1. モデル
顧客・・・注文くれる人
9
出荷・・・出荷した内容
受注・・・注文そのもの
商品・・・弊社が販売しているもの
次ページに記載したユーザー(会社の人間)の関心事により、
もう１つモデルが必要になった。

10. フェーズ1. ドメイン(関心事)
本来、出荷明細書には単価を載せなくてもいい。
10
単価は顧客によって異なるので、その商品で入力した
単価は覚え込みをしてほしい。
覚えこんだ単価であることがわかれば営業への確認
作業がなくなるので、色をつけて表示してほしい。
単価を載せないとお客さんから問い合わせがたくさん
くるのでだるい。価格も明細に記載したい。
顧客と商品の組み合わせによって、単価が変わる。

11. フェーズ1. モデル改訂版
顧客・・・注文くれる人
11
出荷・・・出荷した内容
受注・・・注文そのもの
商品・・・弊社が販売しているもの
単価・・・商品と顧客によって決まる卸売価格
NEW!

12. フェーズ1. (多分)概念モデル図
12
顧客 受注 出荷
商品単価
●がFKをもっているもの
受注は顧客のIDを持ってる。
顧客は受注のIDなど知らん。
受注と出荷はHeader-
Detailになっている。

13. フェーズ1. モデルにメソッドを追加
13
顧客
単価
ü 顧客一覧取得()
ü 顧客特定()
ü 登録()
ü 訂正()
ü 削除()
出荷受注
ü 登録()
ü 訂正()
ü 削除()
ü 商品一覧取得()
ü 商品特定()
ü 単価取得()
商品
ü 最新単価取得()
受注と出荷って、振る舞いが一緒であることに気づいた。

14. フェーズ1. サービス(v1)に切り出す
14
顧客
ü 顧客一覧取得()
ü 顧客特定()
ü 登録(注文オブジェクト)
ü 訂正(注文オブジェクト)
ü 削除(注文オブジェクト)
ü 単価取得(顧客ID,商品ID)
注文
ü 商品一覧取得()
ü 商品特定()
商品
顧客オブジェクト
注文オブジェクト
単価オブジェクト
商品オブジェクト
顧客と商品は特定可能な情報が入ってる。
単価オブジェクトは注文から呼ばれる。で、単価と商品の情報
が入ってる。
注文には各々CRUDがあるため、Stateパターンを適用して、
該当オブジェクトのCRUDが呼び出されるように設計した。

15. フェーズ1. 注文オブジェクトの中身
15
ü ID
ü 登録日付
ü 伝票日付
ü 顧客ID
ü 販売区分(掛売/現金)
ü 総数
ü 粗利
ü 小計
ü 外税
ü 明細オブジェクト
注文オブジェクト
Header-Detailにしたのは集計が必要な総数や粗利や小計などの
処理を簡便化し高速に表示するのが大きな理由。後々伝票単位
での請求処理をラクにするためでもあったけど。
注文明細オブジェクト
ü 明細ID
ü 親ID
ü 商品ID
ü 数量
ü 卸値
ü 定価
ü JANコード

16. 16
Phase Two

17. フェーズ2. 取置残とフリー在庫
Aという商品が倉庫に500個ありまーす。実棚でーす。
17
実はAという商品は2ヶ月前から顧客Bより予約があり、
600個予約がありこの前200個出荷しましたー。
本日、Aという商品は30個倉庫から出荷されまーす。
フリー(余ってる)在庫は、500 – 30 – 400 = 70 個
顧客Bの取置残は、600 – 200 = 400個
実棚の内訳は常にリアルタイムで確認したいとのこと。

18. フェーズ2. 関心事(フリー在庫と取置残)
18
営業の見解
取置残がわからないと、間違って他のお客さんの取置商品を
売ってしまうことになるだろ？いかんでしょ、それは。
それに取置しといて引き取らない or キャンセルされることも
稀にある。他所に回すなら速くしないと売り逃す。ダメダメ。
倉庫の見解
単品の在庫状況を意識しながら出荷作業を行うことはできん。
取置残の管理を倉庫でデイリー棚卸でチェックするのは無理。
出荷作業に集中できないとミスも起きやすい。それは嫌。

19. フェーズ2. 要約してみる
19
フリー在庫
実棚の商品のうち、全く買い手が決まっていない商品のこと。
取置在庫
実棚にある商品のうち、買い手が決まっているけれどもまだ
倉庫内で置いてある商品のこと。
この２つのモデルを生成するには現状のモデルやサービスでは全然無理
なので、新しいモデルを作って設計せなあかん。

20. フェーズ2. モデル(取置残)
20
予約入力
そもそも、どの顧客でどの商品がどれだけ予約されたかを管理
しないとダメだ。入力して顧客別・品番別の集計が必要。
予約出荷
取置元と出荷先が違うことも多い。本社一括で取置をして系列
のお店に各々出荷してくれ、というパターン。
出荷指示の段階で「これは取置から出荷せよ」という情報を
与える必要がある。そうしないと消し込みが出来ない。
A社の取置の出荷ペースが鈍いので、A社の取置をC社に回す
こともある。取置元と出荷先は動的に変更でないとNG.

21. フェーズ2. モデルにメソッドを割当
21
顧客
ü 顧客一覧取得()
ü 予約顧客特定()
ü 系列一覧取得()
ü 登録()
ü 訂正()
ü 削除()
予約
ü 予約商品一覧取得()
ü 予約商品特定()
ü 予約単価取得()
商品
予約モデルを新規作成。
予約内容から受注を入力するときは
「通常の商品ではなく、予約されて
いる商品」の抽出が必要になった。
通常の入力では出荷先を先に決めるが、
予約分の受注入力は最後の出荷先を決定
する上に、系列店の取得も求められた。
受注
ü 予約出荷登録()
ü 予約出荷訂正()
ü 予約出荷削除()

22. フェーズ2. モデルにプロパティを付与
22
取置顧客ID
その受注が予約分から出荷するものであること
その受注が誰の予約分を出荷するのかということ
この2つの条件を満たす最も簡単な方法は、受注モデルに取置顧客IDを
付与すれば良いと判断した。
取置顧客がいるなら、予約の出荷であることが分かる。
同時に誰の取置が減ったのかも分かる。
取置顧客がいない場合はゼロで登録すればよい。
取置顧客IDがゼロ以上の出荷を対象に品番別や顧客別で集計
できれば、残管理も可能になる。
出荷後に顧客別・品番別で残管理ができること。

23. フェーズ2. サービス(v2)に切り出す
23
顧客
ü 取置有無()
ü 系列店取得()
ü 取置残取得()
ü 登録(注文オブジェクト)
ü 訂正(注文オブジェクト)
ü 削除(注文オブジェクト)
注文
ü 予約一覧取得()
ü 予約商品特定()
登録訂正削除はやること一緒。原則、INSERTするだけ。
違うのは対象となる商品の呼び出し。受注時は何でもOKだけど、
予約から受注を打つ時は予約された商品でないとダメ。
系列店の取得は親子関係を顧客に持たせていた為、それを利用。
顧客に取置残取得機能を追加し、検索できるようにした。

24. 24
Phase Three

25. フェーズ3. 受発注と注残管理
弊社は元々数社しか取扱いメーカーが無かった。
25
取扱いメーカー数が、いきなり20社弱に増えた。
OEM生産したオリジナル商材のオワコンになったので、
売上をカバーすべく、他社商品の卸売の拡充を開始。
Excel手管理集計で頑張ろうとしたが、無事死亡した。
欠品商品で入荷予定がある商品は自動で注残にしたい。
もらった注文は無駄には出来ない。

26. フェーズ3. ドメイン
26
注文書
受注
入力
FAX 発注集計
発注の業務フロー
発注
集計 発注書
FAX
内容
確認
Re:FAX内容
反映
内容反映
発注内容を仕入先別に集計し、発注内容を集計する必要がある。
発注内容とメーカーの出荷内容が異なるため、確認が必要。
発注して得られた内容を受注に反映しないと出荷数が決まらない。

27. フェーズ3. ドメイン(N:Nの受発注)
27
本件の辛み
顧客にはどのメーカーも好きな分だけ注文OK、メーカー別に
いくら以上という仕切りはないと伝えていた。
受注は増えたが、複数の受注内容を吸い上げて発注が必要な
商品だけを集めて、仕入先別に分けないといけない。
システムに乗せるとなると、下記の検討が必要だった。
Excelのシートをずらっと並べて手管理していたが、すぐ破綻。
何を持って発注の要否を判断するのか。
発注数と出荷数のズレをどう吸収するのか。
受注N件と発注N件をどうやって一元的に管理するのか。

28. フェーズ3. 受注モデルに新情報付与
28
発注フラグ
発注要否をどうやって判断するか問題。結局フラグにした。
受注登録時に受注数と在庫数を比べてマイナスだったら発注。
発注フラグが立っているものを対象に仕入先別に集計するだけ。
出荷数
受注数を上書きすると元々の顧客の注文数がわからない。
欠品率等の算出のため、受注数と出荷数の差分を管理しないと
実現できなかった。
受注数と発注数は 別で管理しないといけなかった。

29. フェーズ3. 受注モデルに新情報付与
29
状態
受注明細1件1件に状態管理が必要だった。
商品が出せるのか出せないのか、出せないのは何故なのか。
未入荷の商品はキャンセルなのか注残として残すのか。
次回入荷
欠品時の次回納期を顧客に伝える必要があったため。
受注明細の1件1件毎に、状態、次回入荷、発注フラグ、出荷数を追加
することで、受発注の一元管理を実現しようとした。次頁参照。

30. フェーズ3. 受発注管理の目指す姿
30

31. フェーズ3. モデルにメソッドを割当
31
発注
ü 登録()
ü 訂正()
ü 削除()
受発注
ü set発注要否()
受注
ü 発注対象集計()
ü 受発注登録()
ü 発注反映()
発注モデルと受発注モデルを追加。
受発注モデルは「この発注はこの受注から成り立ってます」
という状態を管理するのが責務。
受注明細から発注が必要とされた一覧を仕入先別に集計。
どの受注がどの発注に紐づくかを登録。
メーカーの出荷数から、受注した注文数の出荷数を確定。
受注には発注要否(在庫有無)を登録する処理を追加。

32. フェーズ3. ドメイン(注残管理)
32
注残管理
注文時に商品がないけど、入荷予定が見えており入荷次第納品
できる商品を管理することを、注残管理と言います。
新商品の場合は自動的に注残になる。メーカーが予約注文と
解釈して管理するため。ご予約ですよね、って感じで。
システムに期待された役割は下記の通り。
既存商品の欠品の場合は、全部キャンセル。勝手に送れない。
お客さんの希望があれば、弊社がメーカーに再発注する。
新商品なら自動的に注残に登録しておいてほしい。
欠品の注残希望の場合は再発注が必要なので、入力したら
発注対象に吸い上げて発注先別に集計してほしい。

33. フェーズ3. モデルにメソッドを割当
33
出荷時に新商品を自動的に注残登録する
処理を追加した。
注残は出荷されたかどうかを管理する必要があるため、消込
処理を追加した。
注残
ü 自動登録 ()
ü 登録()
ü 訂正()
ü キャンセル ()
ü 消し込み()
ü 発注対象取得()
ü 検索()
欠品時はキャンセルになるが、別途注残
希望がある場合に手入力での登録が可能
なようにした。
物理削除にしてしまうと、キャンセル
されたログが残らないので論理削除の
キャンセルを追加した。
手入力で注残に追加された商品は、メーカーに再発注をする
必要があったため、要否をフラグで管理するようにした。

34. フェーズ3. サービス(v3)に切り出す
34
受発注
ü 受発注登録()
ü 発注を反映()
ü 登録(注文オブジェクト)
ü 訂正(注文オブジェクト)
ü 削除(注文オブジェクト)
ü 注残商品呼び出し()
注文
発注の登録自体は注文サービスで一本化できた。
受注の登録・訂正時に、発注要否を入れこむメソッドが内部的
に追加された。プライベートメソッドですね。はい。
受発注の紐付登録と、発注内容を受注内容に反映する処理がある。
注残
ü 自動登録 ()
ü 登録()
ü キャンセル ()
ü 消し込み()
ü 発注()
注残モデルがそのままサービスになった。完全に別管理。

35. 35
Phase Four

36. フェーズ4. 売上と請求
今まで出荷明細書を発行し、請求書を作るため今まで
利用していた販売管理ソフトに二重入力していた。
36
月締の請求書の発行を締日と年月を指定するだけで
ボタン１つで可能なように頑張って欲しい…と。
滋賀倉庫での出荷業務がある程度回せるようになった。
伝票発行が出来れば全てのインフラが う。
月締請求のコードは書いたことがなく、かなり頭を
悩ませる事になりました。

37. フェーズ4. 請求書に必要な情報
2015年5月、20日締の請求書を発行するとします。
37
項目名 内容
前回請求額 4月で締めた請求額の合計
前回入金額 4/21∼5/20までに入金された額の合計
繰越額 前回請求額 ー 前回入金額
当月買上額 4/21∼5/20までの納品伝票額の総合計
当月外税額 納品伝票ごとの外税額を足した合計
当月請求額 繰越額 + 当月買上額 + 当月外税額 の合計
納品伝票の番号、金額、外税の一覧表示をする。
合算請求の場合は店舗ごとの合計額を集計して表示する。

38. フェーズ4. 請求書に必要なモデル
38
請求・・・月締めで生成される請求データ
入金・・・先月から当月までに入金された金額合計
売上・・・当月の売上を請求先別に集計した一覧
請求先・・・請求書の送付先
納品先・・・当月売上の集計対象。
請求先と納品先は1:N関係にある。
1:1は単体、1:Nを合算と呼んでいる。

39. フェーズ4. 請求書発行までの流れ
39
発行対象となるのは、下記の3パターン
ロジックに落とすとこうなった
先月請求があって当月買上がある請求先。
先月請求があって当月買上げがないが、繰越がある請求先。
当月買上のみの請求先(要は新規)。
先月の請求データ一覧を取得する。
当月の納品伝票を請求先別に集計。
先月の請求データと同じ請求先が当月売上にあればマージ。
なければ新規投入。
当月の入金総額を請求先別に集計。
請求データ作成後、伝票に請求IDをUPDATEする。

40. フェーズ4. コードでの実現イメージ
40

41. フェーズ4. サービス(v4)に切り出す
41
請求
請求モデルに一本化するしか無かった。
ü 締め期間取得( )
ü 請求データ作成( )
ü 請求データ取得( )
ü 売上集計取得( )
ü 入金総額取得( )
ü 〆解除( )
ü 〆直し( )
ü 伝票ロック( ) etc…
売上・入金・顧客(請求先) が絡むため複雑。
〆るだけではなく解除もやり直しも必要。
締めた伝票は請求を解除しない限り編集不可。
実は、支払請求も全く同じモデルでカバーできる。
売上→仕入,入金→支払,顧客→仕入先。やること一緒。

42. 42
モデルとサービスの変遷

43. フェーズ毎に追加したモデルを整理
43
顧客
出荷(売上)
商品
受注
単価
予約 請求
受発注
発注
フェーズ1 フェーズ2 フェーズ3 フェーズ4
細かい言葉を含めると20強かな。
入金
テーブル数は約40。
注残
既存のコードに対する影響が極小化できた。
ドメインが違うなら、既存ドメインに対して
影響を与えてはいけないように思います。
支払
取置残

44. サービス設計は下記の通り
44
顧客
注文
注文を抽象化して状態を外に出せばどーとでもなる。
受注
ü 登録(注文オブジェクト)
ü 訂正(注文オブジェクト)
ü 削除(注文オブジェクト)
ü 検索(注文オブジェクト)
ü one (注文オブジェクト)
売上 予約 発注 仕入
販売管理はStateパターンが鉄板な気がする。
仕入先
商品 カテゴリ
注残
単価
請求
請求
支払
入金 支払
請求は支払でもやることは変わらない。オブジェクト違うだけ。
データのターンアラウンド性が高いのも特徴。
コア
サービス
受発注

45. 45
で、これってドメイン駆動設計
なの？

46. ドメイン駆動 =
モデルの分割統治
ソフトウエアを利用する人たちの活動と関心事。
ドメイン
大量の情報を要約した、本質的でシンプルなもの。
モデル
常に利用する人たちの関心事が要求仕様となった。
ドメインをモデルで分割統治することをドメイン駆動と
言えばスッキリとした定義になる。オブジェクト指向の
設計指針として何を拠り所にしましょうか、という話？
46

47. まとめ
47
ドメインに構造と秩序を与えるには、ドメイン内で
モデルを構築して、それらを分割統治できる設計に
するのが最良の方法。
ドメインには2つの性質があると思いました。
その最良の方法を目指せという話が、ドメイン駆動
設計という言葉で表現したいことにように思います。
今、実際にその世界で行っていること。
その世界に携わる人の関心事(希望要求不平不満など色々)
未だにドメイン駆動設計用語はよくわかりませんが、
多少なりとも体現できたのであれば嬉しく思います。