Download as PDF, PPTX
![きつね？たぬき？
73
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/d3scala1-161216021347/75/D3-scala-73-2048.jpg)
More Related Content
![[AWS EXpert Online for JAWS-UG 18] 見せてやるよ、Step Functions の本気ってやつをな](https://cdn.slidesharecdn.com/ss_thumbnails/awsxon18howfarstepfunctionsgo-211124111849-thumbnail.jpg?width=640&height=640&fit=bounds)
![[D3]サーバーレスでサービスを作ってみた話](https://cdn.slidesharecdn.com/ss_thumbnails/d3-161107044903-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to 【D3 公開用】ドメイン駆動設計とscala 〜既存プロジェクトへの適用〜
【D3 公開用】ドメイン駆動設計とscala 〜既存プロジェクトへの適用〜
- 1.
- 2.
- 3. アジェンダ 1. 自己紹介 2. HRMOS紹介 3.本編 4. 締め 3
- 4.
- 5. アジェンダ 1. 自己紹介 2. HRMOS紹介 3.本編 4. 締め 5
- 6. 自己紹介 6 角谷 文康（すみや ふみやす）@FScoward ■ 略歴 2011年4月 ～ 2015年7月 TIS株式会社にてクレジットカードシステムの保守開発・新規開発などに従事 - 2014年2月 デブサミ2014登壇 2015年8月 株式会社ビズリーチ入社 2015年8月 ～ 2015年12月 スタンバイ のサーバーサイドエンジニア 2016年1月 ～ 現在 HRMOS採用管理 のサーバーサイドエンジニア 2016年12月（予定） JJUG CCC ■ 好きなもの スフィア、乃木坂46、欅坂46
- 7. アジェンダ 1. 自己紹介 2. HRMOS紹介 3.本編 4. 締め 7
- 8.
- 9. アジェンダ 1. 自己紹介 2. HRMOS紹介 3.本編 4. 締め 9
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17. ■ 出会ったのは MiniSpec という書き方 ● 「ペロリ流 開発要件のまとめ方」 ● http://tech.pero.li/entry/2016/07/22/141228 設計仕様のドキュメントの統一 17
- 18.
- 19.
- 20.
- 23.
- 24.
- 25.
- 26.
- 27.
- 28. Why DDD?（精神面） ■ 「ソフトウェアの核心にある複雑性に立ち向かう」← かっこいい ■ SIerに居た頃は業務がどうなってようが、知ったこっちゃない。言われたと おりに動くものが作れればOKという感じだったが、それが嫌になって事業 会社に転職したので、きちんと業務を理解して、あるべき姿のきれいなシス テム作りをしたかった ■ 我々”一般的な”技術者が解決しなければならないのは技術的問題の前 に、ビジネスの問題であるということを認識しなければならない。 28
- 29.
- 30. ■ 技術的な話は勿論必要だけど、ビジネスとしてやるのなら技術の前にビジ ネスに即してなくちゃだめだよね？ ■ 技術者をやっているとどうしてもテクニックの話によりがちだけど技術は手 段であって目的ではないよね？ ■正しく設計出来てる？？？ ■ ソースコード読んでもなにやってるかわからない。何をしなければいけない のかわからないってどうなの？ ■ 技術的にではなく、ビジネス的に本来の目的を満たしている？ 個人的意見 30
- 31. Scalaでドメイン駆動設計？ 31 ■ Scalaは静的型付け言語なのでドメイン駆動設計と相性がいい（と個人的に は思っている） ■ ちなみにEricEvans本人はRubyが相性が良いかもねと言っている。 ● https://www.infoq.com/jp/articles/eric-evans-ddd-matters-today ● 理由としてはrubyがドメイン固有言語（DomainSpecificLanguage）を簡単に作成できる点にあ る。 ● ドメイン駆動での開発はDSLでメタプログラミングでシステムを作ることなのかもしれない。 ● DSLについて語るつもりはない（というか語れるほど詳しくない）ので、各自調べてみてくださ い。 ● http://www.slideshare.net/yizawa/rubydsl-25541986
- 32.
- 33.
- 34.
- 35.
- 36.
- 37.
- 38.
- 39.
- 40.
- 41.
- 42. ■ DDDは何が解決できるのか ● ソフトウェアの核心にある複雑性に立ち向かう ■何のために用いるのか ● ビジネスロジックへの集中 ■ なぜドメインモデルが必要なのか ● 注視すべきものが一体何なのかを明確にする ● チームとして意思形成を測る 再考：DDDとは 42The Power of PowerPoint - thepopp.com
- 43.
- 44.
- 45.
- 46.
- 47.
- 48.
- 49.
- 50. DDDでなくても機能は満たせる ■ 機能を満たすものだけを作っていくと、どの機能とどの機能が結びついて いてそれぞれがどう関与しているかという知識がバラバラに散らばることに なる ■ だからある業務的な処理を変更したいときに本来はすべての処理が同一 にならなければならないのにそれが漏れたりする ■また、処理的にエラーにはならなくても業務的に間違った処理を行うことに なったりする 50
- 51.
- 52.
- 53.
- 54. ドメインビジョン声明文とは何なのか 54 コアドメインとそれがもたらす価値に関する簡潔な記述を作成すること（約1ページ）。 これが「価値の提議」(value proposition)である。ドメインモデルを他と差別化するもの でない側面は無視すること。スコープを狭い範囲に留めること。この声明文は早期に 作成し、新しい洞察を得たら改訂すること。 ドメインビジョン声明文は 道標として用いられるもので、開発チームを共通の方向に向 かわせ、モデルとコード自体の蒸留を続けさせる。技術系ではないチームメンバや経 営陣、さらには顧客とも共有できる のだ。 エリック・エヴァンスのドメイン駆動設計 第15章 蒸留 p.422
- 55.
- 56.
- 57.
- 58. 最初は書けない、でも書いてみることが重要 ■ 大切なのは今やろうとしているドメインにおいてなにを差別ポイントとして置 くか ■ もたらす価値とは一体何なのかを明示すること ■そして、徐々に徐々に洗練させていくこと ■ DDDは小さな改善の積み重ね ● http://masuda220.jugem.jp/?eid=387 58
- 59.
- 60. 境界づけられたコンテキスト 60 コンテキストとは、Wikipediaを見ると以下のように定義されています。 >言語学におけるコンテクストとは、メッセージ(例えば1つの文)の意味、メッセージとメッセージの関係、言語が発せられた場所や時代の社会環境、 言語伝達に関連するあらゆる知覚を意味し、コミュニケーションの場で使用される言葉や表現を定義付ける背景や状況そのものを指す。 例えば日本 語で会話をする2者が「ママ」について話をしている時に、その2者の立場、関係性、前後の会話によって「ママ」の意味は異なる。2人が兄弟なのであ れば自分達の母親についての話であろうし、クラブホステス同士の会話であれば店の女主人のことを指すであろう 。このように相対的に定義が異な る言葉の場合は、コミュニケーションをとる2者の間でその関係性、背景や状況に対する認識が共有・同意されていなければ会話が成立しない。この ような、コミュニケーションを成立させる共有情報をコンテクストという。 >マーケティングの方法論として、顧客の背景を理解・把握したうえで、それに沿った商品プロモーションを行うことを「コンテクスト・マーケティング」と 呼ぶ。 >情報工学におけるコンテキストは、デバイスが使われている状況を意味する。例えばある時点でデバイスを使用しているユーザーなど。コンテキス トアウェアネスおよびコンテキストスイッチを参照されたい。 >人工知能におけるコンテキストは、意思伝達、言語学、形而上学などに属する部分と深い関係がある。自動的な推論を使ってそれらの観点が如何 にしてコンピュータシステム上でモデル化できるかは、人工知能の研究テーマの1つである。 >シチュエーション・コメディにおけるコンテクストとは、そのショーが公開されている時代背景やその時点の社会の出来事などを意味する。例えば、"I love Lucy"には1950年代のアメリカのコンテクストが反映されている。 >心理学におけるコンテクストとは、フォアグラウンドの事象に伴うバックグラウンドの刺激を意味する。例えば、ネズミがネコを恐れながらエサを探し ているとき、ネコがフォアグラウンドの事象であり、探し回っている場所(および時間)がバックグラウンドの刺激である。海馬にはある種のコンテクスト 処理に特化した神経構造があると考えられている。
- 61.
- 62.
- 63.
- 64.
- 65.
- 66.
- 67.
- 68.
- 69.
- 70. ユビキタス言語の作成 70 まずはドメインエキスパートとじっくりと会話をしてお互いのことばが滑らかに立ち止ま ることなく進むようにお互いの ことばによる理解の齟齬をなくすことを目的として作成 する。 世間一般で通じる言葉を用いる必要はなく、 境界づけられたコンテキスト内で通じる言 葉が出来ればいい ※ ドメインエキスパートとは、業務領域についての深い知識を持っている人物のこと であって必ずしも役職者ではない。
- 71.
- 72.
- 73. きつね？たぬき？ 73 Wikipediaより https://ja.wikipedia.org/wiki/%E3%81%9F%E3%81%AC%E3%81%8D_(%E9%BA%BA%E9%A1 %9E) 関東 関西 きつね 油揚げをのせたそば又はうど ん （きつねうどん、きつねそば） 油揚げの甘煮をのせたうどん （けつね、しのだ） たぬき揚げ玉をのせたそば又はうど ん （たぬきうどん、たぬきそば） 京都：刻んだ油揚げ[21]と青 ねぎをあんかけにしたうどん 又はそば 大阪：油揚げの甘煮またはキ ザミをのせたそば
- 74.
- 75.
- 76.
- 77.
- 78. ドメインモデルに落とし込む 78The Power ofPowerPoint - thepopp.com 1. エンティティ(Entity) 2. バリューオブジェクト(ValueObject) 3. 集約(Aggregate) これら3つの概念を押さえておく必要がある
- 79. Entity 79 ■ Entityは（同一性を）識別することが必要となるモデルのこと ● 簡単に言うと他と区別するためのIDを持たせて管理するということ ■同一性を担保出来れば識別子はなんでも良い
- 80.
- 81.
- 82.
- 83.
- 84. Scala講座 ■ Scalaでは値は基本的にval（イミュータブル）で宣言するのでValueObjectで あることを担保しやすくなっている ● ※var（ミュータブル）で宣言も可能 ■ case classもイミュータブル The Power of PowerPoint - thepopp.com 84
- 85. Scala講座 〜 caseclass について 〜 85The Power of PowerPoint - thepopp.com Scalaでは case class というものがつくれて宣言が簡単になる
- 86. ValueObject 例え話 86 ■ 誕生日をどう表すか ■単純にDate型で表すのかBirthDate型を作るか ■ Dateでやると年齢を別の場所で算出しなければならない ● HRMOS採用管理ではUtilでやっていた ■ BirthDateを用意してcalcAgeのようなメソッドを用意してやったほうが良い
- 87. Entity 例え話 87 ■ 同姓同名の人がいたとしてもそれは別人なので、”人”としてはきちんと識 別する必要がある ●case class Human (id: ID, name: Name, gender: Gender) ■ しかし、”名前”というオブジェクトに注目するとただの文字の羅列でしかな いので、識別する必要はなくValueObjectとして扱えば良い ● case class Name(firstName: String, lastName: String)
- 88.
- 89.
- 90.
- 91.
- 92.
- 93. 集約(Aggregate) 93 ■ エンティティのライフサイクルを同一にするものを集める集約は最小限に ■ keyword: ●トランザクション整合性 ● 結果整合性
- 94. エンティティのライフサイクル 94 エンティティと値オブジェクトを 集約の中にまとめ、各集約の周囲に境界を定義するこ と。各集約に対してルートとなるエンティティを１つ選び、境界の内部に存在するオブ ジェクトへのアクセスは、その ルートを経由して制御すること。外部のオブジェクトが参 照を保持できるのは、ルートのみとすること。内部のメンバに対する一時的な参照を 渡して良いのは、単一の操作で使用する時だけだ。ルートがアクセスを制御するの で、内部が知らないうちに変更されることはなくなる。この取り決めにより、どんな状態 変化においても、集約内にあるオブジェクトと集約全体に対して、不変条件をすべて 強制することが現実的になる。 （エリック・エヴァンスのドメイン駆動設計 p.127 第６章 ドメインオブジェクトのライフサ イクル）
- 95.
- 96.
- 97.
- 98.
- 99. 集約はなぜ難しいのか 99 ■ ビジネス的なライフサイクル？ ■ システム的なライフサイクル？ ■ドメインモデル？ ■ ビューモデル？ ■ 頭のなかで概念が交錯する
- 100.
- 101.
- 102. 集約の勝手な解釈 102 ■ 一つの集約ルート（エンティティ）でどこまで責任を持つかということ ■ モデルの一貫性を保つためのものが集約である ■（参考）http://masuda220.jugem.jp?day=20091126
- 103.
- 104.
- 105.
- 106. パッケージ分けによるサポート 106 ■ controller -コントローラー層 Inputの変換を行う ● model - データを受けとるためのモデル ■ presenter - プレゼンター層 Outputへの変換を行う ● model - データを返すためのモデル ■ application - アプリケーション層 ● service - 調整役。処理の振り分けを行う。 トランザクション制御 もここ。ドメインロジックは存在しては ならない。 ■ domain - ドメイン層 ● model - ドメインモデル。packageで集約をまとめる。ドメインロジックを記 ● service - エンティティや値オブジェクトで行うには 不自然なビジネスロジックを記述 ■ infrastructure - インフラ層 ● repository - 永続化についての責務を負う ■ gateway - ゲートウェイ層。 外部サービスとのやり取りを行う。外部のメールサービスとか ■ util - ユーティリティ
- 107.
- 108.
- 109.
- 110.
- 111.
- 112. 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...