男爵が書く

DDD、オブジェクト指向、技術書の感想など

アルプ株式会社に入社しました

2月1日からアルプ株式会社で働いています。社会人になってから4社目、2年3ヶ月ぶり3度目の転職です。

どんな会社か? 

ググってもまだWantedlyとコーポレートサイトくらいしか出てこないと思うのですが、サブスクリプションビジネス向けの決済基盤・契約管理のSaaSを作っています。元pixiv代表の伊藤さんの会社と言ったほうがピンとくる人が多いかもしれません。開発言語は主にScalaJavaScriptです。実はScalaMatsuri 2019のスポンサー欄にも名前があります。

www.wantedly.com

なぜ転職したのか?

前職のインフィニットループは文句なしに働きやすい会社でした。入社直後から色々やりたがる新人を煙たがりもせず、いくつかのプロジェクトのアーキテクチャ開発プロセスに大いに口を出させてもらえました。カンファレンスへの参加や登壇のサポートもしていただいて、コミュニティで活動する楽しさを知るきっかけにもなりました。お陰様で今では立派なカンファレンスジャンキーです。

www.infiniteloop.co.jp

www.infiniteloop.co.jp

www.infiniteloop.co.jp

転職の動機は端的に言えば、「自分が次にジョインすべきプロジェクトはこれだ」という強烈な確信を抱くに至ったからです。意識的に転職先を探したのではなく、次にいっしょに働きたいチームがたまたま社外にあったという感覚でした。気持ちが固まったのは去年の11月末頃、折しもインフィニットループで携わっていたプロジェクトのリリースが迫っていた頃合いで、次に社内でどう動くか考えていた時分でもありました。

決済基盤との因縁

思えば前々職のpixivにいた頃は決済にまつわるコードばかり書いていた気がします。新しいサービスを作る度、新しい決済方法を追加する度に外部の決済システムのドキュメントを読み込み、サービスに組み込む作業を何度となく繰り返しました。サービス数×決済方法の数だけ実装が増えていくのが辛くなった頃、自社サービス向けの決済基盤をマイクロサービスとして切り出すプロジェクトを立ち上げました。この時、ビジネスサイドの采配を取ってくれたのが伊藤さんでした。伊藤さんとはそれ以前にもBOOTHの立ち上げなどで一緒に仕事をしていて、自分にとってはマネージャーの理想像とも言える人物の一人です。アルプの話を聞いた時、勝手ながらこれは自分たちのプロジェクトの続きだと感じました。しかも今度相手にするのは世の全てのサービスで、扱う問題領域も遥かに複雑になるとなれば、心に火がつくのも無理からぬ話だと思います。

これからどうしたいか

まずはサービスのリリースが最大の課題ですが、同じくらい重要なのは組織の文化を作っていくことだと思います。成熟した会社の性質を変えるのは容易ではないですが、最初期のチーム作りに参加できるのであれば、ここで蒔いた種は会社の成長とともに広がっていくはずです。自分は引き続き札幌からの参加になります。リモートワークという条件は枷にもなりますが、オフィスという場所と固定化された時間に縛られないチームを作ることができれば、それは良い文化の土壌になるのではないかと考えています。

本当の意味での創業期に立ち会うのはこれが初めてです。やるからには今までに経験したことのない、新しい形の組織に育てていきたいと思っています。そして、それが可能だと思える最高のメンバーが集っているのも楽しみなところです。

 

*追記:欲しいものが思いつかなかったのでウィッシュリストを載せていなかったのですが、妻との協議の末、こちらのリストが完成しました。

http://amzn.asia/f1e5lbl

集約とトランザクション境界に関するメモ

この記事はドメイン駆動設計 #1 Advent Calendar 2018の22日目です。

昨日は@crossroad0201さんによる「DDDの構成要素とマイクロサービスの単位をどう合わせるべきか」でした。

今日はエリック・エヴァンスのDDD本に書かれたパターンの一つである集約について、自分なりのまとめを書いてみたいと思います。実は以前まで集約については「言いたいことはわかるが実践で使う意義がいまいち見いだせない」というスタンスだったのですが、最近になってようやく腑に落ちました。

バートランド・メイヤーの契約による設計

DDD本のパターンの多くは、オブジェクト指向プログラミングで築かれてきた理論や原則に基づいたものです。OOPの理論で特に有益なものの一つに、契約による設計というものがります。これは鈍器としても名高い『オブジェクト指向入門』*1の著者であるバートランド・メイヤー博士が提唱したもので、簡単に言えば以下のような設計スタイルのことです。

  • クラスは、そのインスタンスがライフサイクルの間、常に守らなければならないルール(クラス不変表明)を持つ
  • クラスの利用者は、あるオブジェクトのメソッドを呼び出す時、そのメソッドが正しく働くための前提条件(事前条件)を守る義務がある
  • メソッドは事前条件を守って呼び出された限りにおいて、予め定められた契約(事後条件を守る義務がある
  • オブジェクト生成命令(コンストラクタやファクトリメソッド)及び、コマンド(副作用のあるメソッド)は、クラス不変表明を守る義務がある

このスタイルを守ることで、プログラムが想定通りに動かなかった時にどのコードが契約違反を犯したのかが明白になります。また、プログラム言語によってはアサーションという仕組みを使うことで、契約違反の発生を即座に検出することが可能です。これを使うと問題のあるコードが実行されたまさにその場所でアサーションエラーが発生するので、バグの原因調査が著しく楽になります。

この辺りの要点は、@t_wadaさんがスライドにまとめられています。 

【改訂版】PHP7で堅牢なコードを書く - 例外処理、表明プログラミング、契約による設計 / PHP Conference 2016 Revised - Speaker Deck

カプセル化によってドメインの知識を表す

DDDの文脈で言えば、上記のクラス不変表明は、あるエンティティや値オブジェクトの「正しい状態」を宣言することになります。何が正しくて何が正しくないとするかは、扱うドメインとそれをどうモデリングするかによって異なるので、これも一つのドメイン知識と言えるはずです。

例えば、以下のような「金額」値オブジェクトがあったとします。

f:id:dnskimox:20181222144719p:plain
ここで「通貨にアメリカドルが入っていた場合、価格は0以上であり、小数点第二位まで持てる」「通貨に日本円が入っていた場合、価格は0以上であり、小数点以下は持てない」など、そのアプリケーションで「金額」という概念をどのようにモデリングしたのかをコードに落とし込む必要があります。ここがはっきりしていないと、どのような状態のオブジェクトが壊れていない状態なのか、チーム内で共通認識を作れません。

契約による設計の以下のポイントを抑えておけば、オブジェクトのライフサイクル中、これらのルールを確実に守るクラスを記述することができます。

  • オブジェクト生成命令及びコマンドは、クラス不変表明を守る義務がある

オブジェクトが適切にカプセル化されていれば、まさにこのクラス不変表明を守るコードそのものが、ドメインモデルの性質を体現することになるのです。

複数のオブジェクトにまたがる不変表明をどう守るか?

一つのオブジェクトに関する不変表明を守る方法はわかりました。では複数のオブジェクトに言及する不変表明はどのようにコード化すれば良いでしょうか?

ここではECサイトにおける「注文」エンティティと「品目」エンティティについて考えてみます。

f:id:dnskimox:20181222150458p:plain

ここで以下の不変表明を設けたいと思います。

  • 一つの注文は必ず一つ以上の品目を持っている
  • 一つの注文内の品目の商品IDはユニークである

この不変表明を守るのはどのオブジェクトの責務になるのでしょうか?

注文エンティティは自分が所有する品目エンティティへの参照を持っているため、このルールを守ることができそうです。ですが、他のオブジェクトが品目エンティティのコマンドを直接呼び出した場合、注文エンティティはそれによって発生し得るルール違反を止めることができません。

そこで以下のような設計上の規約を設けてみるとどうでしょうか?

  • オブジェクトグループ内の中心的なオブジェクトをルートオブジェクトとする
  • ルートオブジェクトはオブジェクトグループ全体の不変表明を守る義務を持つ
  • ルートオブジェクト以外のオブジェクトのコマンドは、オブジェクトグループの外から直接呼び出してはならないものとする

この規約を守っている限り、オブジェクトグループ全体がカプセル化され、オブジェクトグループが持つ不変表明を守ることができるはずです。

DDDの集約とは、こうした複数のオブジェクトにまたがる、いわば集約不変表明を記述するためのものと捉えることができそうです。

集約不変表明を守るための他のパターン

ファクトリとリポジトリの役割についても、この観点から捉え直すことができそうです。以下のように実装することで、集約のライフサイクルの期間中、常に集約不変表明が担保されるはずです。

  • ファクトリは集約不変表明を守った状態で集約を作り出す
  • リポジトリは必ず集約をまるごと永続化する(部分的に永続化すると不変表明が壊れるため)

契約による設計のルールと似ていると思いませんか?

オブジェクトの正しい状態を担保することは、OOPにおいて重要なテーマの一つです。DDDにおいては、集約の正しい状態を担保することが重要なテーマの一つになっているというわけです。

トランザクション境界の選択指標

さて、一旦DDDの話は置いておいて、今度はデータベースの話をします。

オブジェクトをデータベース(ここではRDBを想定)のレコードとして保存するなら、複数のレコードの状態が不整合にならなように、トランザクションをかけて更新をアトミックにすることが不可欠です。その際、一つのトランザクションで更新する範囲について、相反する二つの要求を踏まえて落とし所を決めることになります。

  • 関連する複数のレコードが不整合にならないために十分広いこと
  • 余分なレコードがロックされないように出来るだけ狭いこと

つまり、トランザクションの範囲は必要十分な広さである必要があるということです。ではその必要十分な広さとはどの範囲のことでしょう?

「関連する複数のオブジェクトがどうなっていれば正しい状態か?」というルールを見つけるのは、ドメインを分析してモデル化する際に重要なポイントです。このルールをドメインモデルに対応するクラス郡(ドメインレイヤー)の中に定義するなら、定義先の第一候補は集約の不変表明になると思います。関連するオブジェクトの整合性が壊れないことを集約が漏れなく保証してくれるなら、集約単位の更新さえアトミックになっていれば不整合は起きないはずです。つまり、

集約の境界と、必要十分なトランザクションの範囲は必然的に一致する

ということになるのではないでしょうか?

 ヴァーン・ヴァーノンの実践DDDには以下のように書かれています。

適切に設計された集約では、業務で必要とするあらゆる変更に対して、トランザクション内での不変条件の整合性を完全に維持できる。また、境界づけられたコンテキストを適切に設計すれば、どんな場合でも、ひとつのトランザクション内で変更する集約をひとつだけに絞りこめる。(実践ドメイン駆動設計 p.340)

これを「ルール」として扱うのは厳しすぎるようにも見えますが、ここまで順序立てて考えてみると、理に適っているように思えてきます。

どこまでも広がる不変表明

と、ここまでの理屈で問題を解決できるアプリケーションなら何ら悩む必要もないのですが、現実は甘くありません。往々にして複数の集約にまたがる整合性をとりたい場面が出てきます。例えばC2Cのショップ作成サイトに以下のような「ショップ」エンティティがあるとします。

f:id:dnskimox:20181222153054p:plain

ここでは注文・品目の場合と異なり、ショップ自体が注文数と総売上の情報を持つこととします。そこで、以下のような不変表明が必要となります。

  • ショップ.注文数  = ショップに対する全ての注文の数
  • ショップ.総売上 = ショップに対する全ての注文.総計の合計

この不変表明を守る責務は誰が担えば良いのでしょうか?

集約のルートをショップにして、注文もその集約に入れるべきでしょうか? もしそんなことをすれば、客が買い物をする際にショップの集約をロックしなければならなくなります。これでは人気のショップに来た客が一人一人レジに並ばされるように、並行性を大きく損なうことになりかねません。

かといってショップの集約と注文の集約に分けてしまった場合、注文の集約が生成・更新された際にショップの集約の情報が更新されることを保証できません。

ですがよく考えてみると、ショップの集約と注文の集約は本当にリアルタイムで整合性が取れている必要があるのでしょうか? もしショップの総売上や注文数をオーナーが見る際、必ずしも「今まさにこの瞬間の数値」を見なくてもいいのであれば、まだ手立てはあります。 

「あとでも良い」整合性

ここで出てくるのが結果整合性という考え方と、ドメインイベントという道具です。

結果整合性とはさきほど言ったような「一定時間経過後に整合性がとれていれば良い」という性質の整合性のことです。通常の整合性は整合か不整合かの二つの状態しかありえませんが、結果整合性であれば「今はまだ不整合だがまもなく整合性がとれる」という状態があり得ます。

ドメインイベントは、ドメインの分析の際に出てくる「◯◯が〜したとき」のような概念をオブジェクト化したものです。ここでは例えば「客が注文した」というドメインイベントを作り、注文の集約を永続化する際にエンキューしておきます。この「集約の永続化とイベントのエンキュー」はアトミックである必要があります。

発行されたドメインイベントはオブザーバーパターンで処理できます。発行者はこのイベントを誰がどのように処理するのかを知る必要はありません。なんらかのサブスクライバ(購読者)が「客が注文した」イベントを受け取り、注文のあったショップの総売上と注文数を更新すれば良いのです。

業務としては結果整合性で構わないが、UI上の都合で複数の集約を更新したいという要望もあるかもしれません。その場合、まずUIが適切かどうかを検討するのも意義があると思います。OOUX等のオブジェクト構造を意識したデザインであれば、自然と集約単位の更新に落ちつていく可能性もありそうです。DDDを効果的に実践するには、ドメインエキスパートと共にデザイナーを巻き込むことも必要になってくると思います。

www.sociomedia.co.jp

理想の世界の外の話

いかがだったでしょうか? 今回説明した道具は以下の3つです。

  • 一つのオブジェクトの整合性はクラス不変表明で担保する
  • オブジェクトのグループの整合性は集約カプセル化して担保する
  • 複数の集約の間ではドメインイベントを使って結果整合性を担保する

これらを駆使すれば、アプリケーション開発で直面する複雑な整合性に関する問題に対して、一貫したアプローチで挑むことができるようになるはずです。

……というのはあくまで理想の世界の話。

現実にはこれらの方法が上手く当てはまらないケースもまま出てきます。ですが「理想論だから切り捨てる」のではなく、まずは理想の形を認識し、そこへ向かって何ができるかを試行錯誤するのが設計者の妙技というものではないでしょうか。

この辺りの議論については、アドベントカレンダー3日目の@k_bigwheelさんが詳しく書かれています。

kbigwheel.hateblo.jp

 

ここまで読んでいただきありがとうございました。

明日は@smdmtsさんです。こうご期待。

参考文献

www.shoeisha.co.jp

www.shoeisha.co.jp

www.shoeisha.co.jp