【JJUG CCC 2016 Fall 公開版】ト?メイン駆動設計とscala ?既存フ?ロシ?ェクトへの適用?
?
3 likes?2,129 views
JJUG CCC 2016 Fall にて発表した資料です。
![きつね？たぬき？
42
Wikipediaより
https://ja.wikipedia.org/wiki/%E3%81%9F%E3%81%AC%E3%81%8D_(%E9%BA%BA%E9%A1
%9E)
関東 関西
きつね 油揚げをのせたそば又はうど
ん
（きつねうどん、きつねそば）
油揚げの甘煮をのせたうどん
（けつね、しのだ）
たぬき 揚げ玉をのせたそば又はうど
ん
（たぬきうどん、たぬきそば）
京都：刻んだ油揚げ[21]と青
ねぎをあんかけにしたうどん
又はそば
大阪：油揚げの甘煮またはキ
ザミをのせたそば](https://image.slidesharecdn.com/jjugcccscala-161205045509/85/JJUG-CCC-2016-Fall-scala-42-320.jpg)
【JJUG CCC 2016 Fall 公開版】ト?メイン駆動設計とscala ?既存フ?ロシ?ェクトへの適用?
- 3. アジェンダ 1. 自己紹介 2. HRMOS紹介 3. 本編 4. 締め 3
- 4. アジェンダ 1. 自己紹介 2. HRMOS紹介 3. 本編 4. 締め 4
- 5. 自己紹介 5 角谷 文康（すみや ふみやす）@FScoward ■ 略歴 2011年4月 ～ 2015年7月 TIS株式会社にてクレジットカードシステムの保守開発?新規開発などに従事 - 2014年2月 デブサミ2014登壇 2015年8月 株式会社ビズリーチ入社 2015年8月 ～ 2015年12月 スタンバイ のサーバーサイドエンジニア 2016年1月 ～ 現在 HRMOS採用管理 のサーバーサイドエンジニア 2016年12月３日 JJUG CCC ■ 好きなもの スフィア、乃木坂46、欅坂46
- 6. アジェンダ 1. 自己紹介 2. HRMOS紹介 3. 本編 4. 締め 6
- 8. アジェンダ 1. 自己紹介 2. HRMOS紹介 3. 本編 4. 締め 8
- 13. 実装の复雑性をどうしようか
- 14. 复雑性に立ち向かう
- 18. DDD!!! 18
- 23. Why DDD?（精神面） ■ 「ソフトウェアの核心にある复雑性に立ち向かう」 ← かっこいい ■ SIerに居た頃は業務がどうなってようが、知ったこっちゃない。言われたと おりに動くものが作れればOKという感じだったが、それが嫌になって事業 会社に転職したので、きちんと業務を理解して、あるべき姿のきれいなシス テム作りをしたかった ■ 我々”一般的な”技術者が解決しなければならないのは技術的問題の前 に、ビジネスの問題であるということを認識しなければならない。 23
- 24. Scalaでドメイン駆動設計？ 24 ■ Scalaは静的型付け言語なのでドメイン駆動設計と相性がいい（と個人的に は思っている） ■ ちなみにEric Evans本人はRubyが相性が良いかもねと言っている。 ● https://www.infoq.com/jp/articles/eric-evans-ddd-matters-today ● 理由としてはrubyがドメイン固有言語（DomainSpecificLanguage）を簡単に作成できる点にあ る。 ● ドメイン駆動での開発はDSLでメタプログラミングでシステムを作ることなのかもしれない。 ● DSLについて語るつもりはない（というか語れるほど詳しくない）ので、各自調べてみてくださ い。 ● http://www.slideshare.net/yizawa/rubydsl-25541986
- 25. ■ 巨大なモデルが存在（一つのclassでデータ持ちすぎ） ● 大きすぎる集約 ■ どのモデルが一体何のためのモデルなのかが明確になっていない ● フロントエンドから受ける/返すためのモデル ● ドメインモデル ● 日付を表すようなYearMonthDateというクラスなどもあったがドメインモデルではない ■ ドメインモデル贫血症に陥っている ● モデルはメソッドをほぼ持っていない ● XXService, XXUtil にビジネスロジックが散らばっている ● ソフトウェアの関心事とビジネスの関心事の分離が出来ていないため処理が複雑に HRMOS採用管理での問題点 25
- 27. モデルとの戦い 27 ■ ApplicationInfoという巨大モデル ■ 応募者を表すモデル ■ なぜか求人情報を持っている ■ なぜか面接情報を持っている ■ しかもこの面接情報のなかには面接評価もある ■ これが内部で使いまわされている ■ しかもこいつはメソッドを持っていない ■ このクラスでフロントエンドへ返している
- 28. HRMOSの問題 28 1. モデルの定義がぐちゃぐちゃ 2. 大きすぎる集約 3. ドメインモデル贫血症
- 30. 1. ユビキタス言語 Domain Driven Design
- 32. ユビキタス言語の作成 32 まずはドメインエキスパートとじっくりと会話をしてお互いのことばが滑らかに立ち止ま ることなく進むようにお互いの ことばによる理解の齟齬をなくすことを目的として作成 する。 世間一般で通じる言葉を用いる必要はなく、 境界づけられたコンテキスト 内で通じる言 葉が出来ればいい ※ ドメインエキスパート とは、業務領域についての深い知識を持っている人物のこと であって必ずしも役職者ではない。
- 34. 2. 境界づけられたコンテキスト Domain Driven Design
- 35. 境界づけられたコンテキスト 35 コンテキストとは、Wikipediaを見ると以下のように定義されています。 >言語学におけるコンテクストとは、メッセージ(例えば1つの文)の意味、メッセージとメッセージの関係、言語が発せられた場所や時代の社会環境、 言語伝達に関連するあらゆる知覚を意味し、コミュニケーションの場で使用される言葉や表現を定義付ける背景や状況そのものを指す。 例えば日本 語で会話をする2者が「ママ」について話をしている時に、その2者の立場、関係性、前後の会話によって「ママ」の意味は異なる。2人が兄弟なのであ れば自分達の母親についての話であろうし、クラブホステス同士の会話であれば店の女主人のことを指すであろう 。このように相対的に定義が異な る言葉の場合は、コミュニケーションをとる2者の間でその関係性、背景や状況に対する認識が共有?同意されていなければ会話が成立しない。この ような、コミュニケーションを成立させる共有情報をコンテクスト という。 >マーケティングの方法論として、顧客の背景を理解?把握したうえで、それに沿った商品プロモーションを行うことを「コンテクスト?マーケティング」と 呼ぶ。 >情報工学におけるコンテキストは、デバイスが使われている状況を意味する。例えばある時点でデバイスを使用しているユーザーなど。コンテキス トアウェアネスおよびコンテキストスイッチを参照されたい。 >人工知能におけるコンテキストは、意思伝達、言語学、形而上学などに属する部分と深い関係がある。自動的な推論を使ってそれらの観点が如何 にしてコンピュータシステム上でモデル化できるかは、人工知能の研究テーマの1つである。 >シチュエーション?コメディにおけるコンテクストとは、そのショーが公開されている時代背景やその時点の社会の出来事などを意味する。例えば、"I love Lucy"には1950年代のアメリカのコンテクストが反映されている。 >心理学におけるコンテクストとは、フォアグラウンドの事象に伴うバックグラウンドの刺激を意味する。例えば、ネズミがネコを恐れながらエサを探し ているとき、ネコがフォアグラウンドの事象であり、探し回っている場所(および時間)がバックグラウンドの刺激である。海馬にはある種のコンテクスト 処理に特化した神経構造があると考えられている。
- 42. きつね？たぬき？ 42 Wikipediaより https://ja.wikipedia.org/wiki/%E3%81%9F%E3%81%AC%E3%81%8D_(%E9%BA%BA%E9%A1 %9E) 関東 関西 きつね 油揚げをのせたそば又はうど ん （きつねうどん、きつねそば） 油揚げの甘煮をのせたうどん （けつね、しのだ） たぬき 揚げ玉をのせたそば又はうど ん （たぬきうどん、たぬきそば） 京都：刻んだ油揚げ[21]と青 ねぎをあんかけにしたうどん 又はそば 大阪：油揚げの甘煮またはキ ザミをのせたそば
- 44. HRMOSの問題 44 1. モデルの定義がぐちゃぐちゃ 2. 大きすぎる集約 3. ドメインモデル贫血症 なぜモデルの定義がぐちゃぐちゃになってしまうのか
- 46. モデルの定義がぐちゃぐちゃ 46 ■ ApplicationInfoという巨大モデル ■ 応募者を表すモデル ■ なぜか求人情報を持っている ■ なぜか面接情報を持っている ■ しかもこの面接情報のなかには面接評価もある ■ これが内部で使いまわされている ■ しかもこいつはメソッドを持っていない ■ このクラスでフロントエンドへ返している
- 48. パッケージ分けによるサポート 48 ■ controller - コントローラー層 Inputの変換を行う ● model - データを受けとるためのモデル ■ presenter - プレゼンター層 Outputへの変換を行う ● model - データを返すためのモデル ■ application - アプリケーション層 ● service - 調整役。処理の振り分けを行う。 トランザクション制御 もここ。ドメインロジックは存在しては ならない。 ■ domain - ドメイン層 ● model - ドメインモデル。packageで集約をまとめる。ドメインロジックを記 ● service - エンティティや値オブジェクトで行うには 不自然なビジネスロジックを記述 ■ infrastructure - インフラ層 ● repository - 永続化についての責務を負う ■ gateway - ゲートウェイ層。 外部サービスとのやり取りを行う。外部のメールサービスとか ■ util - ユーティリティ
- 50. 3. ドメインモデルを見つけ出す Domain Driven Design
- 52. ドメインモデルに落とし込む 52 1. エンティティ(Entity) 2. バリューオブジェクト(ValueObject) 3. 集約(Aggregate) これら3つの概念を押さえておく必要がある
- 53. ドメインモデルに落とし込む 53 1. エンティティ(Entity) 2. バリューオブジェクト(ValueObject) 3. 集約(Aggregate) Entityとは
- 54. Entity 54 ■ Entityは（同一性を）識別することが必要となるモデルのこと ● 簡単に言うと他と区別するためのIDを持たせて管理するということ ■ 同一性を担保出来れば识别子はなんでも良い
- 58. ドメインモデルに落とし込む 58 1. エンティティ(Entity) 2. バリューオブジェクト(ValueObject) 3. 集約(Aggregate) バリューオブジェクトとは
- 60. Scala講座 ■ Scalaでは値は基本的にval（イミュータブル）で宣言するのでValueObjectで あることを担保しやすくなっている ● ※ var（ミュータブル）で宣言も可能 ■ case classもイミュータブル 60
- 61. Scala講座 ? case class について ? 61 Scalaでは case class というものがつくれて宣言が簡単になる
- 62. ValueObject 例え話 62 ■ 誕生日をどう表すか ■ 単純にDate型で表すのかBirthDate型を作るか ■ Dateでやると年齢を別の場所で算出しなければならない ● HRMOS採用管理ではUtilでやっていた ■ BirthDateを用意してcalcAgeのようなメソッドを用意してやったほうが良い
- 64. Entity / ValueObject 例え話 64 ■ 同姓同名の人がいたとしてもそれは別人なので、”人”としてはきちんと識 別する必要がある ● case class Human (id: ID, name: Name, gender: Gender) ■ 一方で”名前”というオブジェクトに注目するとただの文字の羅列でしかな いので、識別する必要はなく識別子を持たずにただの置き換え可能な値 (ValueObject)として扱えば良い ● case class Name(firstName: String, lastName: String)
- 65. 65 Entity / ValueObject 例え話 国民を番号で管理するに当たって名前などを仔細に管理する必要はない 性別も名前も年齢もただの記号でしかないとすれば、 ValueObjectで良い 田中太郎くん（１０） 田中太郎くん（１６）
- 67. 一般人にとっての千円
- 69. 日本银行にとっての千円
- 70. ドメインモデルに落とし込む 70 1. エンティティ(Entity) 2. バリューオブジェクト(ValueObject) 3. 集約(Aggregate) 集約とは？
- 71. 集約(Aggregate) 71 ■ エンティティのライフサイクルを同一にするものを集める集約は最小限に ■ keyword: ● トランザクション整合性 ● 結果整合性
- 72. エンティティのライフサイクル 72 エンティティと値オブジェクトを 集約の中にまとめ、各集約の周囲に境界を定義するこ と。各集約に対してルートとなるエンティティを１つ選び、境界の内部に存在するオブ ジェクトへのアクセスは、その ルートを経由して制御 すること。外部のオブジェクトが参 照を保持できるのは、ルートのみとすること。内部のメンバに対する一時的な参照を 渡して良いのは、単一の操作で使用する時だけだ。ルートがアクセスを制御するの で、内部が知らないうちに変更されることはなくなる。この取り決めにより、どんな状態 変化においても、集約内にあるオブジェクトと集約全体に対して、不変条件をすべて 強制することが現実的になる。 （エリック?エヴァンスのドメイン駆動設計 p.127 第６章 ドメインオブジェクトのライフサ イクル）
- 75. 集約のルール（例） 75 車の速度を上げるのに、タイヤに対して速度を上げるように命令を出すのではなく、車 に対して速度を上げるように命令して、車がタイヤ（エンジン）の回転数を上げるように する
- 76. 集約は非常に難しい 76 ■ オブジェクトのライフサイクルに対する今までの考え方を捨てて集約につい て向き合わなければならない ■ トランザクション整合性？結果整合性？ ■ 全部含んで巨大な集约できちゃうよ???
- 77. 集約はなぜ難しいのか 77 ■ ビジネス的なライフサイクル？ ■ システム的なライフサイクル？ ■ 头のなかで概念が交错する
- 80. たとえばこうなる
- 81. 集約の勝手な解釈 81 ■ 一つの集約のルート（エンティティ）でどこまで責任を持つかということ ■ モデルの一貫性を保つためのものが集約である ■ （参考）丑迟迟辫://尘补蝉耻诲补220.箩耻驳别尘.箩辫?诲补测=20091126
- 84. HRMOSの問題 84 1. モデルの定義がぐちゃぐちゃ 2. 大きすぎる集約 3. ドメインモデル贫血症
- 86. パフォーマンス問題 86 ■ SQLTimeoutが頻発するようになっていた（DDD取り入れる前から） ■ １つのSQLで大量にデータ取りすぎている ■ この問題はDDDでは解決できず、逆にすべてにドメインモデルを強制する とパフォーマンスは劣化する可能性がある
- 87. CQRS(コマンドクエリ責務分離)という考え方 87 ■ DBからデータ引っ張ってちょっとしたデータ表示したいという要求に対して もドメインモデルを用いるべきか？ ■ コマンドとクエリに分け、クエリの場合にはドメインモデルをスキップしても 良いのではないか？ ■ 全部が全部ドメインモデルを用いていてはパフォーマンスに问题ありそう
- 90. ドメインモデルとリポジトリの関係
- 94. HRMOSの問題 94 1. モデルの定義がぐちゃぐちゃ 2. 大きすぎる集約 3. ドメインモデル贫血症
- 96. DDDでよく語られるドメインモデル贫血症 96 ■ HRMOSではScalaを使っているのでgetter, setterは無いがメソッドを持たな いcase class が大量に存在 ■ また、XXServiceやXXUtilといったクラスがあらゆるロジックを持っていたが それを再定義したドメインモデルのクラスに少しずつ移譲 ■ 少しずつリファクタリングを進めて貧血状態から抜け出せるように
- 100. We are hiring! ■ Bizreach: https://bizreach.biz/landing/base_01 ■ HRMOS: https://www.hrmos.co/saiyo/ ■ Stanby: https://jp.stanby.com/ ■ Careertrek: https://careertrek.biz/?trcd=corp ■ Bizreach CAMPUS: https://br-campus.jp/ etc...