Downloaded 13 times
![”ストーリー”ほりさげ(1)
• IDがあります(Entity)
• “シリーズ”がいます
• “作者”がいます
– 作者は原作・作画など複数の可能
性がありますが、横着して一つの
み保持で。
– 【悩んだ】クラス名を「Author」
としているが、日頃「おーさー」
ではなく「作者」と呼んでいるの
で「Sakusya」とすべきか？
• 日本語英語の対応さえ固定してれば
問題無し
• “ページ”が含まれます。
– 第一話
• 1ページ目
• 2ページ目
• …
– “ページ”とはS3上などのURLでア
クセスできる画像を指します。
• “サブタイトル”があります
– “第45話 にゃんこ襲来”
– “#183 eyes of the unknown”
– 読み切り等、サブタイトル無しも
存在なのでOption
pages:List[RemoteFile] =
[ S3(“storyId/1.jpg”),
S3(“storyId/2.jpg”),
… ]
id:StoryId subTitle:Option[String]
seriesId:SeriesId authorId:AuthorId
Storyクラス](https://image.slidesharecdn.com/septeni-scala-3-150616114055-lva1-app6891/75/GANMA-DDD-1-10-2048.jpg)
![”マガジン”ほりさげ(1)
• IDがあります(Entity)
• “タイトル” があります
• “ストーリー”を収録していますが、
ストーリー以外も収録してそうで
す。
– 表紙とか広告とか告知とか。
– ストーリーと静止画を収録できるよ
うにし、”マガジンアイテム”と呼ぶ
ようにします
• “単行本”という考えが方がありま
す
– “同じシリーズ”の話をある程度の話
数でまとめた”マガジン”
– 単行本でないマガジンを”編成本”と
呼んでいます
– 陳列場所が違う
• 編成本 : 新刊タブ
• 単行本 : ランキングタブ
– seriedBindに値があるかどうかで
区別。
• 【悩み】呼び方も機能も違うわ
けだからクラスで別ける必要が
ある気がする
items:List[MagazineItem]=[
StoryItem(storyId),
ImageItem(imageId),
…]
id:MagazineId title:String
seriesBind
:Option[SeriesId]
Magazineクラス](https://image.slidesharecdn.com/septeni-scala-3-150616114055-lva1-app6891/75/GANMA-DDD-1-14-2048.jpg)
![悩んだ： DB → Entity(1)
• DB操作テーブルはInfra層 / Entityは
Domain層
• DB取得結果からEntityを作るとき、素
直に”Entityを作って返す”と書くのは
まずい気がした
– Infra層から上位であるDomain層のメソッ
ド呼び出し
– ID指定でのインスタンス化がどこからでも
出来るのもゆるい感じが。
• あずかり知らないIDを持つEntityが作れてし
まう。
• できれば、ID指定でインスタンス化する手
段はPublicにしたくない感がする
import domain.manga.Series
object SeriesTable {
def get(id) = {
val row = SQL(“select〜…
Series(row[“id”],
row[“title”],
…)
}
}
【インフラ層】
infra/db/manga/SeriesTable.scala](https://image.slidesharecdn.com/septeni-scala-3-150616114055-lva1-app6891/75/GANMA-DDD-1-18-2048.jpg)
![悩んだ： DB → Entity(2)
object SeriesTable{
def get(id){
val row = SQL(“select〜…
(row[“id”],
row[“title”],
…)
}
object SeriesRepository{
def get(row){…
(id, title, authorId,…)
= SeriesTable.get(id)
Series(id, title, authorId, …)
}
というわけで、最初はインフラ層から
はタプルで返して、Domain層でインス
タンスを作っていた。
【ドメイン層】
domain/manga/Series.scala
【インフラ層】
infra/db/manga/SeriesTable.scala
…が面倒すぎた](https://image.slidesharecdn.com/septeni-scala-3-150616114055-lva1-app6891/75/GANMA-DDD-1-19-2048.jpg)
![DB → Entity解法(1)
• 解法① - DAO
– ドメイン層に
生データ ⇔Entity変換のメ
ソッドかクラスを設ける。
– 素直な解法
class SeriesRepository {
def convertToEntity(row:Row)={
Series(row[“id”], row[“title”]…)
}
}
【ドメイン層】
domain/manga/Series.scala](https://image.slidesharecdn.com/septeni-scala-3-150616114055-lva1-app6891/75/GANMA-DDD-1-20-2048.jpg)
Uploaded byYasuyuki Sugitani
GANMA!でDDDをやってみてから1年くらい経った
“Septeni×Scala”勉強会 #3 「ドメイン駆動設計やってみたpart2」 http://septeni-scala.connpass.com/event/15273/ の発表資料です
GANMA!でDDDをやってみてから1年くらい経った
- 1. GANMA!でDDDをやってみて から1年くらい経った Septeni × Scala#3 2015/06/16 杉谷 -配布用-
- 2. 前説 • GANMA!をDDDで作ってみたので、実際 にどういう組み方をしたのかをご紹介し ます。 – リリースしてから1年半分の反省も添えてみ ました。 –甘いところは多いので、突っ込み所を探す感 じでご覧ください
- 3. GANMA!について • 2013/12〜 • スマホ向けの完全オリジナ ルコミックを配信するアプ リ –アニメ化・単行本化も続々 と。 • 以下の3要素 – サーバー – リーダー3種 – 管理ツール群 • 今日はサーバーでDDDを やってみたのお話です。
- 4. 前提@2013 • なんでDDD? – なんか前職で流行ってた。 –詳しくはSepteni×Scala#1の 発表資料をご覧ください。 • DDD扱ったことあった？ – なかった。有給消化中にDDD本を読んでみた だけ。 – Scalaも初挑戦だった。
- 5.
- 6. “マンガ”のモデリング • 始めにGANMA!のマンガ配信業務について 考えます。 – 紙とは違う点も多々ありますが、基本 「週３で漫画雑誌が公開される」というサー ビスです。※今は雑誌形式ではなくなったけど。 •この漫画雑誌を全員で「マガジン」と呼 ぶことにして、ドメインを考えてみまし た。
- 7. “マガジン”と”ストーリー” • “マガジン”の具体例と して、週刊少年ジャン プを考えてみます。 • ジャンプには 「ナルト」の「第313 話」といったように 「第XXX話」が収録さ れています。 •これを“ストーリー”と 呼ぶことにします編集 さんも含めて全員で） 週刊少年ジャンプ <Magazine> ナルト 第1話 <Story> ワンピース 第1話 <Story> …
- 8.
- 9. マガジンに係わる業務を考える 閲覧系 • マガジン情報（と、 それに関するもの） の取得 • マガジンの新刊一覧 を陳列する •シリーズを通しで読 めるマガジンを陳列 する(いわゆる単行 本） 管理業務 • 作家の管理 • ストーリーの管理 • マガジンの編成
- 10. ”ストーリー”ほりさげ(1) • IDがあります(Entity) • “シリーズ”がいます •“作者”がいます – 作者は原作・作画など複数の可能 性がありますが、横着して一つの み保持で。 – 【悩んだ】クラス名を「Author」 としているが、日頃「おーさー」 ではなく「作者」と呼んでいるの で「Sakusya」とすべきか？ • 日本語英語の対応さえ固定してれば 問題無し • “ページ”が含まれます。 – 第一話 • 1ページ目 • 2ページ目 • … – “ページ”とはS3上などのURLでア クセスできる画像を指します。 • “サブタイトル”があります – “第45話 にゃんこ襲来” – “#183 eyes of the unknown” – 読み切り等、サブタイトル無しも 存在なのでOption pages:List[RemoteFile] = [ S3(“storyId/1.jpg”), S3(“storyId/2.jpg”), … ] id:StoryId subTitle:Option[String] seriesId:SeriesId authorId:AuthorId Storyクラス
- 11. ”ストーリー”ほりさげ(2) • “ストーリーリポジト リ”が居ます – 一覧/ 作者別一覧 / シ リーズ別一覧業務 – 保存業務(ストーリー登 録・更新機能) • インフラ層にいる StoryTableとの仲介で す。 • “ページ”はStoryに集 約されており、連動 して保存されたり読 み出されてたりしま す。(リポジトリは居 ない） StoryRepository • get(storyId) • list • findBy(authorId) • findBy(seriesId) • entry(story) • update(story) • delete(storyId) Story … Story StoryTable
- 12. ”シリーズ”ほりさげ(1) • IDがあります(Entity) • “タイトル”があります –≒作品名 – 読み切りでも作品名はあ るので無題は無いはず？ • こっちにも“作者”がいま す。 – ストーリーとシリーズで” 別作者が可能”を意味しま す。 – 実際はほとんどストー リー作者と一致しますが 例外あり • Magazine: ドラクエ4コマ 漫画劇場① • Series:ドラクエ4コマ漫画 劇場（作者：編集部 • Story: 柴田亜美作、衛藤ヒ ロユキ作、… title:Stringid:SeriesId authorId:AuthorId Seriesクラス
- 13. ”シリーズ”ほりさげ(2) • “シリーズリポジト リ”が居ます – 一覧/ 作者別一覧 – 保存業務(シリーズ登 録・更新機能) • インフラ層にいる SeriesTableとの仲介 です。 SeriesRepository • get(seriesId) • list • find(authorId) • entry(series) • delete(seriesId) Series … Series SeriesTable
- 14. ”マガジン”ほりさげ(1) • IDがあります(Entity) • “タイトル”があります • “ストーリー”を収録していますが、 ストーリー以外も収録してそうで す。 – 表紙とか広告とか告知とか。 – ストーリーと静止画を収録できるよ うにし、”マガジンアイテム”と呼ぶ ようにします • “単行本”という考えが方がありま す – “同じシリーズ”の話をある程度の話 数でまとめた”マガジン” – 単行本でないマガジンを”編成本”と 呼んでいます – 陳列場所が違う • 編成本 : 新刊タブ • 単行本 : ランキングタブ – seriedBindに値があるかどうかで 区別。 • 【悩み】呼び方も機能も違うわ けだからクラスで別ける必要が ある気がする items:List[MagazineItem]=[ StoryItem(storyId), ImageItem(imageId), …] id:MagazineId title:String seriesBind :Option[SeriesId] Magazineクラス
- 15. ”マガジン”ほりさげ(2) • “マガジンリポジト リ”が居ます – 一覧 –保存業務(シリーズ登 録・更新機能) – ランキング • 【悩み】ここに居 るのは不適切な気 がする • インフラ層にいる MagazineTableとの仲介 です。 • マガジンアイテムはマガ ジンに集約されていて、 連動して保存されたり読 まれたりします。（リポ ジトリ無し） MagazineRepository • get(magazineId) • list() • search() • delete(magazineId) • entry(magazine) • update(magazine) • ranking() Magazine Magazine MagazineTable …
- 16. 悩んだ： IDの振り方 • IDにはAUTO_INCREMENTを使うことが多いが、 INSERTするまでIDを振れない問題 –採番用のテーブルを作る？ • 実装がすこし手間。 • パフォーマンスと負荷集中とデータ量が怖い – UUID？ • UUIDにはv1とv4がある – v1 : MACアドレスを使っているので生成機材問わず一意保証 – v4 : 乱数。 一意保証無し。怖い。JDK標準搭載のはこれ。 – そのときはSELECT UUID(); を利用した • UUIDv1(NICが無いときはv4)。 • 極端には遅くないだろうし、Slaveでも使えるだろうし。 • ちゃんと調べたらSQL使わずともJavaからv1生成可能だった – Java Uuid Generator (JUG)
- 17. IDの振り方別解 • Snowflake系 – タイムスタンプ+ シーケンス番号 + 何らかの手段で 付与したデバイスID – Scalaを用いて分散IDワーカを実装する (ChwtworkCreator’sNote – かとじゅん氏） • Timestamp(41bit) + データセンターID(5bit) + ワーカー ID(5bit) + シーケンス(12bit) – 軽量なTime-based ID生成器”shakeflake(仮称)”につい て(Smartnews開発者ブログ） • 遅延生成 – 素直に後でIDを生成してセット – 実践ドメイン駆動設計の第5章”エンティティ”に遅延 生成の説明もあり（オススメはしていなかった）
- 18. 悩んだ： DB →Entity(1) • DB操作テーブルはInfra層 / Entityは Domain層 • DB取得結果からEntityを作るとき、素 直に”Entityを作って返す”と書くのは まずい気がした – Infra層から上位であるDomain層のメソッ ド呼び出し – ID指定でのインスタンス化がどこからでも 出来るのもゆるい感じが。 • あずかり知らないIDを持つEntityが作れてし まう。 • できれば、ID指定でインスタンス化する手 段はPublicにしたくない感がする import domain.manga.Series object SeriesTable { def get(id) = { val row = SQL(“select〜… Series(row[“id”], row[“title”], …) } } 【インフラ層】 infra/db/manga/SeriesTable.scala
- 19. 悩んだ： DB →Entity(2) object SeriesTable{ def get(id){ val row = SQL(“select〜… (row[“id”], row[“title”], …) } object SeriesRepository{ def get(row){… (id, title, authorId,…) = SeriesTable.get(id) Series(id, title, authorId, …) } というわけで、最初はインフラ層から はタプルで返して、Domain層でインス タンスを作っていた。 【ドメイン層】 domain/manga/Series.scala 【インフラ層】 infra/db/manga/SeriesTable.scala …が面倒すぎた
- 20. DB → Entity解法(1) •解法① - DAO – ドメイン層に 生データ ⇔Entity変換のメ ソッドかクラスを設ける。 – 素直な解法 class SeriesRepository { def convertToEntity(row:Row)={ Series(row[“id”], row[“title”]…) } } 【ドメイン層】 domain/manga/Series.scala
- 21. DB → Entity解法(2) •解法② - 依存性逆転の原則 – 実践DDD p118 – 定義(trait/interface)は domain層で、実装はinfra層 を可とする • DB->Entityは普通にinfra層で インスタンスを作って返す – なんとなく気持ちが悪いが、 最近はこれ系を愛用中。 • 実践DDDには他の方法も 載っています。 class SeriesTableResult extend Series { … } trait Series { val id:SeriesId val title:String … } 【ドメイン層】 domain/manga/Series.scala 【インフラ層】 infra/db/manga/SeriesTable.scala
- 22. APP層でやっていること例 • 閲覧系 – マガジン情報（と、それに関 するもの）の取得 •MagazineRepositoryを叩くだけ – マガジンの一覧やランキング • MagazineRepositoryのlistやら Rankingを叩くだけ • 管理業務 – 作家の管理 1. 必要入力を受け取る 2. Authorオブジェクトを作る 3. entryする。 4. あとはget/list 5. JSON出力 – ストーリーの管理 1. 必要入力を受け取り”下書 き”を作る – Storyと似たフィールド構成 だが、NULLABLEが多い 2. 下書きをストーリーに変換 する 3. entryする 4. あとはget/list 5. JSON出力 – マガジンの編成 • 格納したいマガジンアイテム の一覧を受け取る • Magazineを作る • entryする
- 23. 実装上の反省 • RepositoryとTable操作系をobjectにしてし まった – テストが大変 –コンテキストが絡まざるを得ない事をすると きにも大変 • パフォーマンスチューニングやトランザクション – DI出来るように徐々に改修中 • Repository系でFutureを使わなかった – チューニングを極められない
- 24. やってみてどうだったか • DDD良い – 実践しきれてるかどうかはわからないけど、それでも良い 感じ。 –編集者も含めて、用語を合わせるのは混乱が少なくて良い。 • 説明が同じになると、動員できる知恵が多くなり、ドメインを 捕らえる精度が上がって、ますます良い。 • ドメイン層の実装が、口頭説明と同じになるのはわかりやすい。 – ドメイン層に徹底的に余計なことを書かないようにするの は、とても見通しが良い。 • 大きめのリファクタを決断しやすい。口頭説明でおかしさを感 じたら、リファクタ決断の時
- 25.
- 26.
- 27.
- 28. Septeni × Scala勉強会 #3 〜 ドメイン駆動設計やってみた(2) 〜
- 29. 2回目のテーマ：ドメイン駆動設計 チャットワーク株式会社 加藤潤一 さん Play2 withDDD 〜何からはじ めて何に気をつけるべきか〜 セプテーニオリジナル 原田侑亮 Scala : DDD × 弊社実践例 本勉強会について 本日のトピック 社内研修を兼ねつつ、セプテーニの知名度向上を目標としたもの 1回目のテーマ：Scala普及について チャットワーク株式会社 加藤潤一 さん Scala関数プログラミング初級 セプテーニオリジナル 杉谷保幸 Scalaに至るまでの物語 セプテーニオリジナル 寺坂郁也 新卒で初めて学ぶ言語が Scalaで良かったこと／大変だったこと ※資料はconnpassにて共有されています
- 30.
- 31.
- 32. 書籍化・アニメ化も決定! オリジナルコミックアプリ 最強ネット広告運用支援システム 10代少女に人気・ファッションアプリ ・Playframework +Scala ・AngularJS + TypeScript ・DDD採用 ・Unit Test 完備 ・スクラム ・Android + Scala ・Swift ※検証中 ・Playframework + Scala ・AngularJS + TypeScript ・DDD採用 ・Unit Test 完備 ・スクラム ・Sisioh(http://sisioh.org/) …for ・弊社最後のLAMP構成 ・レガシーコード改善ガイド活用 技術トピック ・スクラム ・Android + Kotolin
- 33.
- 34. 本日のテーマ：ドメイン駆動設計(2) セプテーニオリジナル 杉谷保幸 GANMA!でDDDをやってみてから1年くらい経った セプテーニオリジナル 原田侑亮 「DDD× 新人」が学んでみたレシピ共有 20:10 - 21:00 -