弊社(SepteniOriginal)にてDDDを実践したはじめの一歩のご紹介です。 in English This is first step of Domain Driven Design in my company.

1. SCALA × × DDD × 弊社実践例

2. AGENDA
 自己紹介と前提話
 DDDとScalaを実践したプロセス
 Scalaでの実践
 DDDを採用する上でのあるある失敗談
 そして僕らもハマった。
 最後に

3. 自己紹介と前提話
嫁からみた僕はこんなのらしい
（嫁に描いてもらいました。）

4. 自己紹介と前提話
自己紹介(SCALA風味)
/* 原田侑亮さんを実装してみた。*/
class YusukeHarada extends V2TeamMember with
SepteniOriginalEngneer with SepteniOriginalEmployee {
val beforeJob = “C Engineer”
val skills = Seq(“C” , “C#” , “VBA” , “Scala” , “etc…”)
def basicWork() = {
writeContextMap()
convertContextMapToDomain()
executeCoding() /* Include Coding TestCode */
writeTest ()
}
// Todo: VV-1234で実装します！
def espcialyWork() = ???
def study () = ???
def hobby () = ???
}

5. 自己紹介と前提話
伝えたいこと
 エリックが何いってるかわからない件な人
 DDD考えるキッカケになれば…
 Scalaやってるんだけど…
 是非プロジェクトに合わせてDDDを採用していただけるとっ
かかりになれば…
 ScalaもDDDもやってます。
 ごめんなさい！だいぶ、初歩的な第一歩のお話になってし
まいますが、生暖い目で見守っていただければ…
 ScalaもDDDもやっていないけど技術的に興味が…
 是非是非、弊社にお越しください。

6. 自己紹介と前提話
WHY DDD ？の前に
DDDで統一できる！

7. 自己紹介と前提話
WHY DDD ？
 長期保守が必要になるアプリケーションの開発に
なると予測できた。
 以外と広告って複雑
 エンジニアとディレクターの会話の溝があった
 ソシャゲを開発していたころのお話ですが…
 社内で流行り始めてた。
 先生がいた。
 カトジュン先生ありがとうございます。

8. 自己紹介と前提話
WHY
 会社戦略としてScala流行らせたかった。
 僕ははじめは別にC#でもいいじゃん。と思ってた。
（過去）
 DDDのコンテキストマップをそのままコードに落
とせる。
 get { return hoge; } を書かなくてもよい
 コードが少ない。
 やみつきですね。もう、C#すら、めんどくさい。

9. DDDを実践したプロセス

10. DDDを実践したプロセス
ユビキタス言語
 ユビキタス言語の確立
 実はコレがめんどくさい。
 メンバーが多ければ多いほどめんどくさい。
 しかし、コレがベースになるので重要
 弊社ではどうやっているのか？
1. ストーリーからEntity ・ VO ・振る舞いを抽出する
2. POと相談する。
3. ドメイン図をアップデート
4. エンジニアとPOで再度レビュー
POは日本語→英語の翻訳でしっくりくるか確認

11. DDDを実践したプロセス
コンテキストマップ
 コンテキストマップの作成
 コンテキストマップって
 アプリケーションの世界地図かく感じです。
 イギリス地図ですらいろいろな解釈があるため、答えはありま
せん。

12. DDDを実践したプロセス
ドメイン図
 ドメイン図レビュー（弊社特化施策）
 コンテキストマップをクラス図っぽく起こしたものです。
 ユビキタス言語としてドメイン図と呼称することにしました。
 では、目の前でやってみましょう！

13. DDDを実践したプロセス
実践例（お題）
 サンプルプロジェクト
 弊社プロジェクトで、スケジュール管理が出来るWebアプリ
ケーションを作ることになりました。
すでにログイン機能は実装されており、ユーザーはシステム
からは判別出来る状態になっています。
 ユーザーストーリー
1. イベント管理者はイベントを登録できる。
2. イベント管理者はイベントに日付候補と詳細を登録できる。
3. イベント管理者は、自分以外のユーザーを招待できる。
4. ユーザーは、イベントの日付候補に○☓△をつけられる。
5. ユーザーは、○が多い日付を閲覧できる。

14. DDDを実践したプロセス
実践例（お題）
 ユーザーストーリー
 まずは名詞を抽出
 これらがEntityないしVOになりうる。
1. イベント管理者はイベントを登録できる。
2. イベント管理者はイベントに日付候補と詳細を登録できる。
3. イベント管理者は、自分以外のユーザーを招待できる。
4. ユーザー ⇒ POに追求すると「イベント参加者」は、イベ
ントの日付候補に○☓△をつけられる。
5. ユーザーは、○が多い日付を閲覧できる。

15. DDDを実践したプロセス
実践例（お題）
 ユーザーストーリー
 次に動詞
 これらがEntityもしくはVOの振る舞いになる。
1. イベント管理者はイベントを登録できる。
2. イベント管理者はイベントに日付候補と詳細を登録できる。
3. イベント管理者は、自分以外のユーザーを招待できる。
4. ユーザー ⇒ POに追求すると「イベント参加者」は、イベ
ントの日付候補に○☓△をつけられる。
5. ユーザーは、○が多い日付を閲覧できる。

16. DDDを実践したプロセス
実践例（まとめ）
 いかがだったでしょうか？
 今回は、プロジェクターを使用するためにCacooでやってお
りますが、普段は以下の図の通り付箋とどこでもホワイトボー
ドでやってます。

17. SCALA での実践
 DDDフレームワーク
org.sisioh.dddbaseの導入
 カトジュンさんお手製のDDDをするためのフレームワーク
 サンプルコード
 Google認証で投稿できるしょっぱい掲示板
 https://bitbucket.org/saxia/board

18.  ProductOwnerによるTraitレビュー
 SepteniのPO = コード書けない
 DDDではエンジニア・非エンジニアは関係ない！
 val/defさえ読めればドメインレビューができます！
SCALA での実践

19. DDDを採用する上でのあるある
失敗談
 技術に引っ張られる。
 ドメインはやっぱりドメインエキスパートと一緒につくりあげる
ものです。
 技術でドメイン捻じ曲げるのは良くないよね。
 エンジニアも凛とした心で業務（ドメイン）に向きあいましょう。
 技術のマリオネットになってはいけない。

20. DDDを採用する上でのあるある
失敗談
 逆流現象
 インフラ層がドメイン層を知ってしまっている。
 ORマッパー便利ですよね。
 けど、ORマッパーで作ったオブジェクトをそのまま使うと…
 ドメイン層がアプリ層を知ってしまっている。
 Formもオブジェクトで来る時代
 ドメインにそのままForm渡しちゃってない？
 どうするの？
 プロジェクト分割！
 http://qiita.com/t_hirohata/items/6c7d22a9a29f8263690d

21. DDDを採用する上でのあるある
失敗談
 エリックが言っていることがわからない件
 500ページもあるし、しょうが無いよね
 だからこうやってプレゼンしてます。大丈夫です。
 めげずに読みましょう。
 読んでみて困ったら、カトジュンさんがタイム
チケット売っていらっしゃるのでそちらへ
https://www.timeticket.jp/j5ik2o

22. まとめ
 DDDをやるなら！
 ユビキタス言語を制定しよう！
 コンテキストマップ（全体俯瞰図）を書いて、
本当に必要なものだけのやりとりを意識しよう
 ドメインを考えるときは技術を忘れよう！
 ScalaでDDDやるなら
 org.sisioh.dddbaseを使うと便利！
 特にEntityとRepository周り！
 とりあえず、非エンジニアな方もこれだけ教えれば読める
 val は要素
 def は振る舞い
 protected とかprivate ついてたら読まなくていいよ！
 プロジェクト分割で逆流を抑えよう。

23. まとめ？
 冒頭でも記載しましたが、SepteniOriginalでは積極採
用しています。
 DDDに興味がある方
 Scalaを試したい方
 是非是非ともに弊社にお越しください！
笑って開発できる現場を提供いたします！

24. ご清聴ありがとうございました！