読者です 読者をやめる 読者になる 読者になる

かとじゅんの技術日誌

技術の話をするところ

混乱しがちなサービスという概念について

DDD Scala

社内でサービスがよくわからないという話になったので、考察を少しまとめておきます。

過去のエントリでも以下のように触れましたが、もう少しかみ砕いてみよう。

サービスという言葉はあいまい まず、簡単に前提の整理から。単に"サービス"って言葉が何を指すのか結構曖昧です。 サービスは簡単にいうと手続きとか振る舞いのことですが、細かくいうと、PofEAAでいうサービスと、DDDいうサービスは、目的が異なります。前者はアプリケーションのためにドメインモデルを再利用可能にするためのものです。後者はドメインの知識を表している振る舞いです。これはのちほど詳しく説明します。 まぁこのあたりは具体例がないと理解しがたいですが、レイヤーの違いによって責務が異なるという感じです。DDDのサービスの章では、サービスには、アプリケーション層、ドメイン層、インフラストラクチャ層と、複数のレイヤーに存在すると言及されています。PofEAAのService Layerは、DDDでいうアプリケーション層のサービス(以下 アプリケーションサービス)に相当すると思います。

ServiceとDCIについて - かとじゅんの技術日誌

サービスは抽象的でわかりにくい。特にDDDのレイヤー化アーキテクチャのレイヤー分割という概念を踏まえないと混乱する原因になりますので、レイヤーの定義から入りましょう。

続きを読む

CQRS+Event Sourcingを学ぶための教材

DDD CQRS Event Sourcing Akka

超久しぶりのブログ…。 Octopressに疲れたのではてなブログに戻ってきました(Octopressの過去の記事ははてなブログにインポート済です)。ついでプロに移行。

さて、海外のDDDコミュニティではCQRS+Event Sourcing(以下, ES)が人気なのですが、ようやく日本でも話題になることが多くなったので今回は教材となりそうな書籍を簡単に紹介したいと思います。

DDD といえば まず エリック・エヴァンスのドメイン駆動設計 (以下 DDD本) を読むべきですが、CQRSについては記載がないので 実践ドメイン駆動設計 を読みましょう。

実践ドメイン駆動設計

実践ドメイン駆動設計

さらにDDD本には ES の基礎となる ドメインイベント の解説が含まれていません。そのドメインイベントの概要を掴みたければ、実践ドメイン駆動設計に記載があります。

より実装イメージを掴みたいという人には、以下の本がお勧めです。ただし、コードはC#ですが、より実装視点での知見が得られる本です。

.NETのエンタープライズアプリケーションアーキテクチャ 第2版 (マイクロソフト公式解説書)

.NETのエンタープライズアプリケーションアーキテクチャ 第2版 (マイクロソフト公式解説書)

非同期でノンブロッキングなアーキテクチャでC10K問題を解決するには、Scalaでの実装手段はいろいろあると思いますが、Akkaはその一つです。また、AkkaはDDD+CQRS+ESへの考慮も為されいるツールキットです。ということで、AkkaでDDDをやる場合、参考になるのは以下の書籍らしいです。実践ドメイン駆動設計 の著者(Vaughn Vernon氏)が書いた書籍で、設計上の概念のみならずAkkaでの実装例なども紹介されています。

Reactive Messaging Patterns with the Actor Model: Applications and Integration in Scala and Akka

Reactive Messaging Patterns with the Actor Model: Applications and Integration in Scala and Akka

さらに読書会もあるので、興味がある方は参加してみてはどうでしょうか?(僕も参加する予定)

ddd-cqrs-es.connpass.com

あと、gihub上の参考になるコード例としては以下をあげておきます。ddd-leaven-akka-v2は、akka-dddをベースしたサンプルです。コード量は結構あるので読むには気合いがいると思いますが…。先に上の書籍で概念を押さえてからの方が無難です。

GitHub - pawelkaczor/ddd-leaven-akka-v2: Next generation of ddd-leaven-akka

GitHub - pawelkaczor/akka-ddd: Akka/EventStore DDD framework

関連するブログ記事はこちらです。

Reactive DDD with Akka | Write less, do more!

Reactive DDD with Akka - lesson 2 | Write less, do more!

Reactive DDD with Akka - lesson 3 (Projections) | Write less, do more!

DDD+CQRS+ESとは直接的に関係ないのですが、Reactive Messaging Patterns with the Actor Model: Applications and Integration in Scala and Akka でよく引用されている書籍です。Akkaで提供されている機能のほとんどは、EIPを読むと理解できると思います。

Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (Addison-Wesley Signature Series (Fowler))

Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (Addison-Wesley Signature Series (Fowler))

Java EE読書会のドキュメントも併読すると参考になるかもしれません。 EIP - Java EE勉強会

なぜCQRSやESが必要になったのかは、別のエントリで書く予定。

ServiceとDCIについて

Scala DCI DDD

面白そうなネタがあったので、自分なりの考えをまとめてみる。

Ruby/Rails 用 DI コンテナ Dee をつくった、あるいは Ruby のカルチャーについて

この記事はRuby用のDIコンテナの話題なんですが、DCIについても言及されているようです。比較軸はDIそのものというより、サービスとDCIだと思うので、それについてダラダラといくつか考えをまとめてみます。多分返事になるようでならないかも。それと宗教上の都合でDDDの視点から書きます...。

サービスという言葉はあいまい

まず、簡単に前提の整理から。単に"サービス"って言葉が何を指すのか結構曖昧です。
サービスは簡単にいうと手続きとか振る舞いのことですが、細かくいうと、PofEAAでいうサービスと、DDDいうサービスは、目的が異なります。前者はアプリケーションのためにドメインモデルを再利用可能にするためのものです。後者はドメインの知識を表している振る舞いです。これはのちほど詳しく説明します。
まぁこのあたりは具体例がないと理解しがたいですが、レイヤーの違いによって責務が異なるという感じです。DDDのサービスの章では、サービスには、アプリケーション層、ドメイン層、インフラストラクチャ層と、複数のレイヤーに存在すると言及されています。PofEAAのService Layerは、DDDでいうアプリケーション層のサービス(以下 アプリケーションサービス)に相当すると思います。

あわせて読んで欲しいのはこのあたり。

ここではDDDでいうところの、ドメイン層のサービス(以下 ドメインサービス)に焦点を絞って考えてみます。

あと、ここでいうモデルというのはドメインモデルとします。DCIのDataもドメインモデルの前提。

オブジェクトはメンタルモデルを写し取るもの

いきなり話は変わってしまいますが、オブジェクト指向の成り立ちの話を少し

DCIアーキテクチャ - Trygve Reenskaug and James O. Coplien - Digital Romanticism から印象的な下りを紹介。

事実、オブジェクト指向プログラミングにおける先駆者たちの目的は、エンドユーザのメンタルモデルをコードにおいてとらえることだった。

そもそも、オブジェクト指向は、人間のメンタルモデルをシミュレーションするための問題解決手法として登場したので、これは素直に理解できます。源流をたどればAlan KayのDynabook構想とか出てきますね。この記事を読んでもらうとわかりますが、DCIもメンタルモデルに近づくための手法の一つです。

一方、DDDですが、Kent BeckはDDDに対する謝辞でこんなことを綴っています。

「ソフトウェアの設計を、今取り組んでいる問題ドメインのメンタルモデルに適合させるにはどうすればよいか、ということについて、Eric Evansは素晴しい本を警いた。」

あと、DHHは、おすすめ書籍のリストの中でこのように述べています。

Evans’ book, Domain-Driven Design, is great. It offers a mental framework for thinking deeper about the abstraction of object oriented programming.

DDDでも、"ユビキタス言語(DDD P24)"や"モデル駆動設計(DDD P45)"という手法を利用しますが、メンタルモデルを実装に反映するためにあります。

どちらも、オブジェクトはメンタルモデルを写し取るものだというスタンスは一致しているといえます。メンタルモデルを反映するのはドメインモデルなので、やはりメンタルモデルの主戦場はドメイン層だと思います。アプリケーションサービスじゃなくて、ドメインサービスの話を重視するのはこのためです。

続きを読む

ScalaでのDCIの実装を考える

DCI DDD Scala

みなさん、こんばんわ。

会社のアドベントカレンダーで、Scalaコードでわかった気になるDDDというブログを書いたのですが、最近、老害を防ぐためにDCIについても勉強中です。

DCIアーキテクチャ - Trygve Reenskaug and James O. Coplien

とりあえず、これを読めということらしいですが、今ひとつ理解できなかったので、

Lean Architecture: for Agile Software Development

を買って読んでます(巻末にScalaのコード例もあってなかなかよさげです)。

この本ではtraitのmix-in方式を紹介しているのですが、この方法はイマイチだと思っているので、別の方法を考えてみたのでさくっと紹介します。

続きを読む

ドメインモデルの関連を表現するには

DDD Scala

(Scala前提の記事なので注意してください)

たとえばこんなモデルがあって、相互に依存しているケースを考えよう。

注意:説明を簡単にするために、varを利用しています。

従業員

class Employee(
  val id: Long,
  val name: String,
  var department: Option[Department] = None
)

部署

class department(
  val id: Long,
  val name: String,
  var employees: Seq[Employee] = Seq.empty
)

利用例

val employee = new Employee(1, "KATO")
val department = new Department(1, "Dev")

employee.department = Some(Department) // (1)
department.employees = Department.employees + employee // (2)

加藤という従業員が開発部に所属する状態を表しています。 これの何が問題かってわかりますか?

続きを読む

シナリオ -> モデル -> コード ->

昨日もDDDの話題を少ししたので、シナリオ→モデル→コードのサイクルについて身近な例を踏まえてネタを提供できないかと思った。何でもいいんだけど、鍼とか整体とかマッサージとか一度は行った経験あると思うので、そのドメインで考えてみるか。

続きを読む

ユビキタス言語とドメインモデル、そしてモデル探索のうずまき

最近、ドメイン駆動設計ってどうやって実践すればいいかなーという質問をよくされるので、この記事が満額回答にはならないと思いますが、書いてみたいと思います。

シンプルな問題はトランザクションスクリプト、いわゆる手続き型で対処できます。問題が小さいのでコードは直接的でわかりやすくなる傾向にあります。 とはいえ、世の中の問題はシンプルなものばかりじゃない。複雑な問題もある。DDDの著者であるEric氏は、複雑な問題はドメインモデルを使って対処すべきと説く。

ドメインとは問題の領域とか知識の範囲をいうのですが、DDDはそのドメインにある概念をモデル(ドメインモデル)として定義して、さらに実装として紐付けていく設計手法です。

続きを読む