ScalaMatsuri 2016

1. Heads-on Domain
Driven Development
in Scala
Yoshitaka Fujii
@yoshiyoshifujii
2016 ScalaMatsuri
Scalaでドメイン駆動設計に真正面から取り組んだ話

2. Who am I ?
• Yoshitaka Fujii
• @yoshiyoshifujii
• Joined MOTEX in April, 2014
• Web Application Engineer
• Scala (7 months)
Java, Python
自己紹介。エムオーテックス株式会社。Scala歴7ヶ月。

5. We are looking for
a Scala of Engineers !!
Scalaエンジニア募集中!!

7. Isn't it difficult?
難しくないですか ?

8. Design
approach
設計手法に過ぎない。

9. and
Design
Pattern
あと、デザインパターン

10. Let’s implement !!
さあ、実装しよう!!

11. https://goo.gl/DQB6Ak

13. too difficult …
難しい…

14. Today’s
topic
今日、お話したいこと

15. Amateur
Team
ScalaもDDDも経験の無い私たちのチームが

16. Hard
Fighting
日々悩み悪戦苦闘した内容について

17. I'd like to share
what we
learned!!
同じような悩みを持つ皆様の一助になればうれしく思います。

18. Agenda
• Layered Architecture
• CQRS
• is-a Root Entity
• Message
アジェンダです。

19. Layered Architecture
レイヤー化アーキテクチャについて

20. Reprinted from Eric Evans (2003, pp.68) Domain Driven Design.

21. Review
おさらい

22. Point of
Layered Architecture
レイヤー化アーキテクチャの要約。

23. Point of Layered Architecture
1. To clarify the responsibilities of the layer
2. Depends only on the lower layer
3. Isolating the Domain
レイヤーの責務を明確にすること。下位レイヤーだけに依存す
ること。ドメインを隔離すること。

24. User Interface Layer
• Showing information to the user.
• Interpreting the user’s commands.
• The external actor might sometimes be
another computer system rather than a
human user.
ユーザに情報を表示する。ユーザからのコマンドを解釈する。
外部アクタは別のコンピュータシステムのこともある。

25. Application Layer
• Defines the jobs the software.
• Directs the expressive domain objects to work
our problems.
• This layer is kept thin.
• It does not contain business rules or
knowledge.
ソフトウェアの仕事を定義、ドメインオブジェクの問題解決を
導く。薄く保つ。ビジネスルールや知識を含まない。

26. Domain Layer
• Concepts of the business.
• Information about the business solution.
• Business rules.
• This layer is the beat of business software.
ビジネスの概念。ビジネスが置かれた状況に関する情報。ビジ
ネスルール。ビジネスソフトウェアの核心。

27. Infrastructure Layer
• Provides generic technical capabilities that
support the higher layers.
• Message sending for the application.
• Persistence for the domain.
• Drawing widgets for the UI
上位レイヤを支える技術的機能を提供。Applicationのための
メッセージ送信。Domainのための永続化。UIの描画。

28. First wall
最初の壁
https://goo.gl/ErmMRx

29. We wondered how the
tasks within a layer
can be implemented...
どのようにレイヤーの責務を実装しようか…

30. User Interface Application Domain Infrastructure

31. User Interface Application Domain Infrastructure
ViewModelForm Entity
Record
SQL
JSON Entity
Result Set
ViewModel

32. Form
• So-called Form
• It express POST data from view.
• Making corresponding to each View.
いわゆるForm。ViewからのPOST/PUTデータを表す。

33. case class XxxForm(email: String, name: String)
def form(): Form[XxxForm] =
Form(
mapping(
"email" -> email,
"name" -> nonEmptyText(maxLength = 80))
(XxxForm.apply)(XxxForm.unapply))

34. ViewModel
• Synonymous with the MVVM pattern
• Holding a state for drawing a view.
• Form => Application => Domain
MVVMパターンのViewModelと同義。Viewを描画するための
状態の保持。UI=>Application=>Domainと受け渡す。

35. case class XxxForm(email: String, name: String)
case class XxxViewModel(email: String, name: String)
def convertForm2ViewModel(form: XxxForm):
XxxViewModel =
XxxViewModel(
form.email,
form.name)

36. User Interface Application Domain Infrastructure
ViewModelForm Entity
Record
SQL
JSON Entity
Result Set
ViewModel

37. User Interface Application Domain Infrastructure
ViewModelForm Entity
Record
SQL
JSON Entity
Result Set
ViewModel
Form =>
ViewModel
ViewModel
=> Entity
Entity => SQL

38. User Interface Application Domain Infrastructure
ViewModelForm Entity
Record
SQL
JSON Entity
Result Set
ViewModel
Form =>
ViewModel
ViewModel
=> Entity
Entity => SQL
ResultSet =>
Record
Record =>
Entity
Entity =>
ViewModel
ViewModel
=> JSON

39. So we tried, but...
と、いうことですが…

40. Second wall
次の壁
https://goo.gl/ErmMRx

41. When we implemented,
the responsibilities started
to leak across
the boundaries.
実装してみると、責務の境界が、混じるようになりました。

42. User Interface
x
Domain
たとえば、User Interface に Domain が。

43. def xxxForm(id: Option[Long]): Form[XxxForm] = Form(
mapping(
"name" -> nonEmptyText(maxLength = 128)
.verifying(“error.uniqueness.name",
!service.isSameNameExisting(_, id)),
"path" -> nonEmptyText(maxLength = 128),
"lockVersion" -> optional(longNumber))
(XxxForm.apply)(XxxForm.unapply))

44. Application
x
Domain
たとえば、Application に Domain が。

45. private def validateExists(vm: ViewModel):
Either[Error, ViewModel] = {
repository.findBy(vm.email) match {
case Some(_) => Left("not exists!")
case None => Right(vm)
}
}

46. Need a plan to make the
boundaries more clear
境界を見失わないための工夫が必要。

47. Thinking…
どのようにレイヤーの責務を実装しようか…

48. Communication
コミュニケーション

49. Review
レビュー

50. Analysis Modeling
分析モデリング

53. To clarify the responsibilities
of the layer
• Communication
• Review
• Analysis Modeling
レイヤーの責務が混じらないよう、コミュニケーションと
Reviewと分析モデリングを活用した。

54. Third wall
次の壁
https://goo.gl/ErmMRx

55. Those pesky Services
曲者のService。

56. Service
of three types
3つのService

57. Partitioning Services into Layers
• Application Service
• Domain Service
• Infrastructure Service
アプリケーション層、ドメイン層、インフラ層のそれぞれにサ
ービスってありますよね。

58. Reprinted from Eric Evans (2003, pp.107) Domain Driven Design.

59. How do we know which
service to use when?
どう責務を使い分けています?

60. Overuse of Services leads
to leakage of Domain
knowledge to other layers.
Serviceを多用するとDomainロジックが流出しがち。

61. Thinking…
3つのServiceをどのように扱うか…

62. Responsibility of Service
• Once, approach to Application Service.
• Temporarily forgive the outflow of Domain
logic.
• Repeat to consider refactoring.
Application Serviceに寄せる。Domainロジックの流出を一時
的に許容。Refactoringを繰り返し検討。

63. Refactoring
リファクタリング

64. Scrum
スクラム

65. Day of Refactoring
リファクタリングをする日

66. STOP knowledge leaks
• Refactoring
• Scrum
• Day of Refactoring
ドメインの知識の流出を、リファクタリング、スクラム、リフ
ァクタリングする日を使って継続的に改善した。

67. Forth wall
次の壁
https://goo.gl/ErmMRx

68. too many conversion logics
コンバート処理が多いですよね?

69. User Interface Application Domain Infrastructure
ViewModelForm Entity
Record
SQL
JSON Entity
Result Set
ViewModel
Form =>
ViewModel
ViewModel
=> Entity
Entity => SQL
ResultSet =>
Record
Record =>
Entity
Entity =>
ViewModel
ViewModel
=> JSON
1 2 3
4567

70. 7 conversions
just for a roundtrip
いって、かえってするだけなのに、7回も…

71. Just live with it!!
仕方ない!！

72. Some sacrifices
are unavoidable
to isolate the Domains.
Domainを隔離するためなら、多少の犠牲はやむを得ない!!

73. Domain isolation = DDD !!
Domainを隔離することが、DDDだ!!

74. Conversion makes the
Domain boundaries clear
Convertすることで、Domainの境界も分かりやすい

75. Responsibility is
easy to understand
in isolation.
責務が分離され、分かりやすい

76. Still, too many
conversions...
とはいえ、Convert処理多いよなー

78. Command
Query
Responsibility
Segregation
コマンドクエリ責務分離

79. Agenda
• Layered Architecture
• CQRS
• is-a Root Entity
• Message
CQRS

80. CQRS
• CQRS stands for
Command Query Responsibility Segregation
• First proposed by Greg Young
• Martin Fowler
http://martinfowler.com/bliki/CQRS.html
Greg Youngが提唱したのをMartin Fowlerがブログで紹介し
た。

81. About CQRS
• CQS (Command query separation)
• It states that every method should either be a
command that performs an action
• or a query that returns data to the caller
• but not both
あらゆるメソッドは、「コマンド」もしくは「クエリ」のいず
れか一方で、その両方はダメ。

82. In the first place…
そもそも…

84. Tackling Complexity
in the Heart of Software
ソフトウェアの複雑さに立ち向かう

85. View the list
一覧を表示する

86. User Interface Application Domain Infrastructure
ViewModelForm Entity
Record
SQL
JSON Entity
Result Set
ViewModel
Form =>
ViewModel
ViewModel
=> Entity
Entity => SQL
ResultSet =>
Record
Record =>
Entity
Entity =>
ViewModel
ViewModel
=> JSON

87. more complexity ?
複雑にしてない?

88. Query Model
呼び出し元にデータを戻す「クエリ」について。

89. User Interface Application Domain Infrastructure
ViewModelForm
Record
SQL
JSON
Result SetForm =>
ViewModel
ViewModel
=> SQL
ResultSet =>
Record
QueryModel
=> JSON
Record =>
QueryModel
QueryModel

90. Query Model
• Query Model into the Infrastructure Layer
• Application Layer direct connection to
Infrastructure Layer
• Result Set => Record => Query Model
• Query Model is returned to User Interface
Layer
Infrastructure層にQuery Modelを作る。 Application層から直接
Infrastructure層。 Query ModelはUser Interface層まで持ち込みOK!!

91. Command Model
何らかのアクションを実行する「コマンド」について。

92. User Interface Application Domain Infrastructure
ViewModelForm Entity
Record
SQL
JSON Entity
Result Set
ViewModel
Form =>
ViewModel
ViewModel
=> Entity
Entity => SQL
ResultSet =>
Record
Record =>
Entity
Entity =>
ViewModel
ViewModel
=> JSON

93. Command Model
is simple
Layered Architecture
Command Model は従来のレイヤー化アーキテクチャ

94. Many of
the business logic
is Command.
ビジネスロジックの多くはCommand

95. Command tends to be
smaller than Query
Command Modelがシステムの占める割合は少なめ

96. Summary of CQRS
• Simple retrieval process is separated into
queries.
• Direct connection to the Infrastructure Layer.
• Simple things made simply.
単純な取得処理はクエリとして分離。直接インフラ層にアクセ
ス。シンプルなものはシンプルに作る。

97. Agenda
• Layered Architecture
• CQRS
• is-a Root Entity
• Message
ROOTエンティティがis-aの関連を持っている場合

98. is-a Root Entity
ROOTエンティティがis-aの関連を持っている場合

99. Root Entity
has
is-a
Root Entityをis-aの関連とする設計にすることってありますよ
ね？

101. is-a
is confusing
is-aの関連をRoot Entityにするとややこしい。

102. One Repository ?
or
Two Repository ?
Repositoryは、1つ？2つ？

104. Should the parent track the
children?
親が子をしっているの？

106. Awkward in terms of OO
オブジェクト指向的に変

107. Should the Service specify
the children?
クライアントが子を指定するの？

109. Awkward in terms of the
aggregation
集約の概念的に変

110. Take a look
at the source code
コードで見てみる

111. trait RootEntity {
val id: Option[Long]
val name: String
}
case class Sub1(
id: Option[Long], name: String)
extends RootEntity
case class Sub2(
id: Option[Long], name: String)
extends RootEntity

112. Parent tracking the children
集約の親が子を知っているパターン

113. trait RootEntityRepository {
object Sub1Repository { def save(entity: Sub1): Option[Sub1] = ??? }
object Sub2Repository { def save(entity: Sub2): Option[Sub2] = ??? }
def save(types: String, entity: RootEntity) = {
types match {
case "Sub1" => Sub1Repository.save(entity)
case "Sub2" => Sub2Repository.save(entity)
case _ => None
}
}
}
object RootEntityRepository extends RootEntityRepository

114. trait Service {
def createSub1 = {
val sub1 = Sub1(None, "sub1")
RootEntityRepository.save("Sub1", sub1)
}
def createSub2 = {
val sub2 = Sub2(None, "sub2")
RootEntityRepository.save("Sub2", sub2)
}
}

115. Service specifying the
children
サービスが子を指定するパターン

116. trait RootEntityRepository[E <: RootEntity] {}
trait Sub1Repository {}
trait Sub2Repository {}
object Sub1Repository
extends RootEntityRepository[Sub1]
with Sub1Repository
object Sub2Repository
extends RootEntityRepository[Sub2]
with Sub2Repository

117. trait Service {
def createSub1 = {
val sub1 = Sub1(None, "sub1")
Sub1Repository.save(sub1)
}
def createSub2 = {
val sub2 = Sub2(None, "sub2")
Sub2Repository.save(sub2)
}
}

118. Which pattern is
more suitable...
どっちのケースが適しているか…

119. To clarify the hierarchy
どのヒエラルキーに属するRepositoryか明示する。

120. trait RootEntityRepository[E <: RootEntity] {}
trait Sub1Repository {}
trait Sub2Repository {}
object Sub1Repository
extends RootEntityRepository[Sub1]
with Sub1Repository
object Sub2Repository
extends RootEntityRepository[Sub2]
with Sub2Repository

121. It eliminates
redundant processing
冗長な処理を簡略化する。

122. trait RootEntityRepository {
object Sub1Repository { def save(entity: Sub1): Option[Sub1] = ??? }
object Sub2Repository { def save(entity: Sub2): Option[Sub2] = ??? }
def save(types: String, entity: RootEntity) = {
types match {
case "Sub1" => Sub1Repository.save(entity)
case "Sub2" => Sub2Repository.save(entity)
case _ => None
}
}
}
object RootEntityRepository extends RootEntityRepository

123. Summary of is-a Root Entity
• Service specifying the children
• To clarify the hierarchy
• It eliminates redundant processing
Serviceが子を知っているパターンを採用

124. Agenda
• Layered Architecture
• Dependency Injection
• is-a Root Entity
• CQRS
• Message
最後にMessageについて。

125. Message

126. Low Layer
浅いレイヤーのエラーメッセージはUIに直接返せる

127. Deep Layer
深いレイヤーのエラーメッセージはそう簡単じゃない

128. Infrastructure Layer
インフラ層

129. Unrecoverable
Exception
復旧不可能な例外

130. Domain Layer
ドメイン層

131. I want to return
a message
on the screen
なんらかのメッセージを返したい

132. Type of Message
• Option
• Either
• Try
• Validation

133. Option
• Some or None. Why None ?
• None is Exception
• Exception is Exception
SomeかNoneで、なぜNoneか分からない。Noneがそもそも
異常なこともある。その場合は例外にしたい。

134. Either
• Left or Right. Left is error message.
• Monad (salaz)
• Single message only
Left or RightでLeftにメッセージが詰められる。Monadなコ
ーディング可能。ただしメッセージは1つ。

135. Try
• Define the type of Exception
• Simple error handling
• Throw to the higher layer
例外の型を定義。throw形式でエラー時の制御が容易。処理を
中断し上位のレイヤーまで到達可能。

136. Validation (Scalaz)
• Return the stack error
• But not Monad
• not be used in for-yield
• Applicative
エラーを詰めて返すことが可能。Monadではない。for式で使
えない。Applicative。

137. Stack ?
or not
エラー時のメッセージをStackしたいか、したくないか。

138. Validation
したいならValidation。

139. or not
Try (or Either)
したくないならTry (or Either)

140. But …
ただし…

141. Validation is
Applicative.
not Monad.
ValidationはApplicativeであり、Monadではないよね。

142. sealed abstract class Validation[+E, +A]
final case class Success[A](a: A)
extends Validation[Nothing, A]
final case class Failure[E](e: E)
extends Validation[E, Nothing]

143. def ap[EE >: E, B](x: => Validation[EE, A => B])
(implicit E: Semigroup[EE]): Validation[EE, B] = (this, x)
match {
case (Success(a), Success(f)) => Success(f(a))
case (e @ Failure(_), Success(_)) => e
case (Success(f), e @ Failure(_)) => e
case (Failure(e1), Failure(e2)) => Failure(E.append(e2, e1))
}

144. case class Person(name: String, age: Int)
def validateName(name: String) =
if (name.length > 1) name.successNel
else "invalid name".failureNel
def validateAge(age: Int) =
if (age >= 0) age.successNel
else "invalid age".failureNel

145. scala> (validateName("Yoshida") |@| validateAge(27))
(Person)
res0: scalaz.Validation[scalaz.NonEmptyList[String],Person]
= Success(Person(Yoshida,27))
scala> (validateName("") |@| validateAge(-1))(Person)
res1: scalaz.Validation[scalaz.NonEmptyList[String],Person]
= Failure(NonEmptyList(invalid name, invalid age))

146. Summary of Message
• Unrecoverable exception
• Domain Layer return a message to screen
• Validation or Try or Either
復旧不可能な例外もあるが、ドメイン層から何らかのメッセー
ジを返したいとき、ValidationとTry(or Either)を使い分け。

147. Summary
まとめ

148. Scala
Scalaで悪戦苦闘

149. Scala x DDD
ScalaとDDDでさらに苦悩

150. We hope this was
helpful to you!!
同じような悩みを持つ皆様の一助になればうれしく思います。

151. Thank you for
your attention.
ご清聴ありがとうございました。