かとじゅんの技術日誌

Rustでブロッキングキューを実装する

2023-12-22T00:00:00+09:00

Rustでブロッキングキューを実装した話。これはRustのカレンダー | Advent Calendar 2023 - Qiitaの22日目の記事です。

ブロッキングキューはご存じだろうか。(えっ…スレッドはブロックしたくない…と思った人は最後まで読むとよいかも)

Javaにはあります。

docs.oracle.com

要素の取得時にキューが空でなくなるまで待機したり、要素の格納時にキュー内に空きが生じるまで待機する操作を追加でサポートしたりするQueueです。

これはRustの標準にはない。今回はブロッキングキューを実装してみる。

「そういえば、ブロッキングキューが欲しい！」と思ったときに、ぜひこのブログ記事を思い出してほしい。

まず作るな・既存のコードを調査しろ

標準にはないが、クレートとして実装がある。

JimFawcett/RustBlockingQueueとjulianbuettner/rust-blockinqueueをみるとMutextとCondvarを使うと実装できるということが分かる。TeaEntityLab/fpRustではmpscを使っている模様。

MutexとCondvarがあれば実装できることがわかる。詳しいことは以下参照

詳解 Rustアトミック操作とロック ―並行処理実装のための低レイヤプログラミング

作者:Mara Bos
オーム社

Amazon

この本にもMutex,Condvarの使い方の紹介がある。

BlockingQueueのインターフェイス

JavaのAPIを参考にインターフェイスは以下のようにした。

queue-rs/src/queue.rs at f4de43386432b0d9873af07e7cbba41e6133a75f · j5ik2o/queue-rs · GitHub

pub trait BlockingQueueBehavior<E: Element>: QueueBehavior<E> + Send {
  /// Inserts the specified element into this queue. If necessary, waits until space is available.<br/>
  /// 指定された要素をこのキューに挿入します。必要に応じて、空きが生じるまで待機します。
  ///
  /// # Arguments / 引数
  /// - `element` - The element to be inserted. / 挿入する要素。
  ///
  /// # Return Value / 戻り値
  /// - `Ok(())` - If the element is inserted successfully. / 要素が正常に挿入された場合。
  /// - `Err(QueueError::OfferError(element))` - If the element cannot be inserted. / 要素を挿入できなかった場合。
  /// - `Err(QueueError::InterruptedError)` - If the operation is interrupted. / 操作が中断された場合。
  fn put(&mut self, element: E) -> Result<()>;

  /// Inserts the specified element into this queue. If necessary, waits until space is available. You can specify the waiting time.<br/>
  /// 指定された要素をこのキューに挿入します。必要に応じて、空きが生じるまで待機します。待機時間を指定できます。
  ///
  /// # Arguments / 引数
  /// - `element` - The element to be inserted. / 挿入する要素。
  ///
  /// # Return Value / 戻り値
  /// - `Ok(())` - If the element is inserted successfully. / 要素が正常に挿入された場合。
  /// - `Err(QueueError::OfferError(element))` - If the element cannot be inserted. / 要素を挿入できなかった場合。
  /// - `Err(QueueError::InterruptedError)` - If the operation is interrupted. / 操作が中断された場合。
  /// - `Err(QueueError::TimeoutError)` - If the operation times out. / 操作がタイムアウトした場合。
  fn put_timeout(&mut self, element: E, timeout: Duration) -> Result<()>;

  /// Retrieve the head of this queue and delete it. If necessary, wait until an element becomes available.<br/>
  /// このキューの先頭を取得して削除します。必要に応じて、要素が利用可能になるまで待機します。
  ///
  /// # Return Value / 戻り値
  /// - `Ok(Some(element))` - If the element is retrieved successfully. / 要素が正常に取得された場合。
  /// - `Ok(None)` - If the queue is empty. / キューが空の場合。
  /// - `Err(QueueError::InterruptedError)` - If the operation is interrupted. / 操作が中断された場合。
  fn take(&mut self) -> Result<Option<E>>;

  /// Retrieve the head of this queue and delete it. If necessary, wait until an element becomes available. You can specify the waiting time.<br/>
  /// このキューの先頭を取得して削除します。必要に応じて、要素が利用可能になるまで待機します。待機時間を指定できます。
  ///
  /// # Arguments / 引数
  /// - `timeout` - The maximum time to wait. / 待機する最大時間。
  ///
  /// # Return Value / 戻り値
  /// - `Ok(Some(element))` - If the element is retrieved successfully. / 要素が正常に取得された場合。
  /// - `Ok(None)` - If the queue is empty. / キューが空の場合。
  /// - `Err(QueueError::InterruptedError)` - If the operation is interrupted. / 操作が中断された場合。
  /// - `Err(QueueError::TimeoutError)` - If the operation times out. / 操作がタイムアウトした場合。
  fn take_timeout(&mut self, timeout: Duration) -> Result<Option<E>>;

  /// Returns the number of elements that can be inserted into this queue without blocking.<br/>
  /// ブロックせずにこのキューに挿入できる要素数を返します。
  ///
  /// # Return Value / 戻り値
  /// - `QueueSize::Limitless` - If the queue has no capacity limit. / キューに容量制限がない場合。
  /// - `QueueSize::Limited(num)` - If the queue has a capacity limit. / キューに容量制限がある場合。
  fn remaining_capacity(&self) -> QueueSize;

  /// Interrupts the operation of this queue.<br/>
  /// このキューの操作を中断します。
  fn interrupt(&mut self);

  /// Returns whether the operation of this queue has been interrupted.<br/>
  /// このキューの操作が中断されたかどうかを返します。
  ///
  /// # Return Value / 戻り値
  /// - `true` - If the operation is interrupted. / 操作が中断された場合。
  /// - `false` - If the operation is not interrupted. / 操作が中断されていない場合。
  fn is_interrupted(&self) -> bool;
}

データ構造

今回のブロッキングキューとは別に前提となるtraitがQueueBehaviorです。ブロッキングしないキューの責務をQueueBehavior traitとして定義しています。型パラメータQはこのトレイトを実装していなければなりません。Q以外にConvarの2個がタプルでまとめてArcにラップされています。Cloneが実装されているので、cloneしてもArcなので同じデータを参照する。pは要素の型を保持するためのもの。is_interruptedは操作を中断させるためのフラグとなる。

#[derive(Debug, Clone)]
pub struct BlockingQueue<E, Q: QueueBehavior<E>> {
  underlying: Arc<(Mutex<Q>, Condvar, Condvar)>,
  p: PhantomData<E>,
  is_interrupted: Arc<AtomicBool>,
}

putメソッド

putは「指定された要素をこのキューに挿入します。必要に応じて、空きが生じるまで待機します。」という機能。空きがない場合はメソッド内でスレッドをブロックするので制御が戻ってこなくなる。

putのテスト

putのテストを書いてみた。キャパシティ一杯になるとブロックする。

  #[test]
  #[serial]
  fn test_blocking_put() {
    init_logger();

    let mut q = create_blocking_queue(QueueType::VecDeque, QUEUE_SIZE);
    let mut q_cloned = q.clone();

    let please_interrupt = Arc::new(CountDownLatch::new(1));
    let please_interrupt_cloned = please_interrupt.clone();

    let handler1 = thread::spawn(move || {
      // キューにデータをputする
      for i in 0..QUEUE_SIZE.to_usize() {
        let _ = q_cloned.put(i as i32).unwrap();
      }
      assert_eq!(q_cloned.len(), QUEUE_SIZE);

      // 割り込みを要求する
      q_cloned.interrupt();
      // QUEUE_SIZEを超えたputなのでブロックするはずだが
      // すでにinterruptされているので割り込みエラーが発生する。
      match q_cloned.put(99) {
        Ok(_) => {
          panic!("put: finish: 99, should not be here");
        }
        Err(err) => {
          log::debug!("put: finish: 99, error = {:?}", err);
          let queue_error = err.downcast_ref::<QueueError<i32>>().unwrap();
          assert_eq!(queue_error, &QueueError::InterruptedError); 
        }
      }
      // 割り込みが検出されると割り込み状態がリセットされることを確認する
      assert!(!q_cloned.is_interrupted()); 

      please_interrupt_cloned.count_down();
      // 先にputするのでブロックが発生するが
      // 非同期にinterruptされるので割り込みエラー
      match q_cloned.put(99) {
        Ok(_) => {
          panic!("put: finish: 99, should not be here");
        }
        Err(err) => {
          log::debug!("put: finish: 99, error = {:?}", err);
          let queue_error = err.downcast_ref::<QueueError<i32>>().unwrap();
          assert_eq!(queue_error, &QueueError::InterruptedError);
        }
      }
      assert!(!q_cloned.is_interrupted());
    });

    // カウントが0になるまでブロックする
    // つまり最初のputのテストが終わるまで待機する
    please_interrupt.wait();
    assert!(!handler1.is_finished());
    // 非同期に割り込みを行う
    q.interrupt();
    handler1.join().unwrap();
  }

putの実装

仕様は「指定された要素をこのキューに挿入します。必要に応じて、空きが生じるまで待機します。」。実装は以下。

queue-rs/src/queue/blocking_queue.rs at f4de43386432b0d9873af07e7cbba41e6133a75f · j5ik2o/queue-rs · GitHub

空きがある場合は2)はスルーされて5)だけ実行される。空きがないつまりフルの場合は、2)の内部に入り、4)がnot_fullのwaitを呼び出すとスレッドをブロックする。 takeメソッド内で要素を取得するときにnot_full.notify_onceが実行されると、not_fullのwaitが解除される(待機しているスレッドが複数ある場合そのうち一つだけが解除される)。

impl<E: Element + 'static, Q: QueueBehavior<E>> BlockingQueueBehavior<E> for BlockingQueue<E, Q> {
// ...
  fn put(&mut self, element: E) -> Result<()> {
    // 1) underlyingから必要な要素を取得する
    // queue_vec_mutexは内部キュー、not_fullのConvar, not_emptyのConvar
    let (queue_vec_mutex, not_full, not_empty) = &*self.underlying;
    let mut queue_vec_mutex_guard = queue_vec_mutex.lock().unwrap();
    // 2) 内部キューがフルのときにはループする
    while queue_vec_mutex_guard.is_full() {
      // 3) 割り込みのチェック
      if self.check_and_update_interrupted() {
        log::debug!("put: return by interrupted");
        return Err(QueueError::<E>::InterruptedError.into());
      }
      log::debug!("put: blocking start...");
      // 4) 空きが生じるまで待機する
      queue_vec_mutex_guard = not_full.wait(queue_vec_mutex_guard).unwrap();
      log::debug!("put: blocking end...");
    }
    // 5) 内部のキューにofferを使って挿入する
    let result = queue_vec_mutex_guard.offer(element);
    // 6) not_emptyを使って通知する
    not_empty.notify_one();
    result
  }
// ...
}

takeメソッド

takeは「このキューの先頭を取得して削除します。必要に応じて、要素が利用可能になるまで待機します。」という機能。要素がない場合はメソッド内でスレッドをブロックするので制御が戻ってこなくなる。

takeのテスト

  #[test]
  #[serial]
  pub fn test_blocking_take() {
    init_logger();

    let mut q = populated_queue(QueueType::VecDeque, QUEUE_SIZE);
    let mut q_cloned = q.clone();

    let please_interrupt = Arc::new(CountDownLatch::new(1));
    let please_interrupt_cloned = please_interrupt.clone();

    let handler1 = thread::spawn(move || {
      // キューにデータをputする
      for _ in 0..QUEUE_SIZE.to_usize() {
        let _ = q_cloned.take().unwrap();
      }

      // 割り込みを要求する
      q_cloned.interrupt();
      // QUEUE_SIZEを超えたtakeなのでブロックするはずだが
      // すでにinterruptされているので割り込みエラーが発生する。
      match q_cloned.take() {
        Ok(_) => {
          panic!("take: finish: should not be here");
        }
        Err(err) => {
          log::debug!("take: finish: error = {:?}", err);
          let queue_error = err.downcast_ref::<QueueError<i32>>().unwrap();
          assert_eq!(queue_error, &QueueError::InterruptedError);
        }
      }
      assert!(!q_cloned.is_interrupted());

      please_interrupt_cloned.count_down();
      // 先にtakeするのでブロックが発生するが
      // 非同期にinterruptされるので割り込みエラー
      match q_cloned.take() {
        Ok(_) => {
          panic!("take: finish: should not be here");
        }
        Err(err) => {
          log::debug!("take: finish: error = {:?}", err);
          let queue_error = err.downcast_ref::<QueueError<i32>>().unwrap();
          assert_eq!(queue_error, &QueueError::InterruptedError);
        }
      }
      assert!(!q_cloned.is_interrupted());
    });

    // カウントが0になるまでブロックする
    // つまり最初のtakeのテストが終わるまで待機する
    please_interrupt.wait();
    assert!(!handler1.is_finished());
    // 非同期に割り込みを行う
    q.interrupt();
    handler1.join().unwrap();
  }

takeの実装

仕様は「このキューの先頭を取得して削除します。必要に応じて、要素が利用可能になるまで待機します」。実装は以下。

queue-rs/src/queue/blocking_queue.rs at f4de43386432b0d9873af07e7cbba41e6133a75f · j5ik2o/queue-rs · GitHub

要素が一つでもある場合は2)はスルーされて5)だけ実行される。要素がないつまり空の場合は、2)の内部に入り、4)がnot_emptyのwaitを呼び出すとスレッドをブロックする。putメソッド内で要素を取得するときにnot_empty.notify_onceが実行されると、not_emptyのwaitが解除される(待機しているスレッドが複数ある場合そのうち一つだけが解除される)。

  fn take(&mut self) -> Result<Option<E>> {
    // 1) underlyingから必要な要素を取得する
    let (queue_vec_mutex, not_full, not_empty) = &*self.underlying;
    let mut queue_vec_mutex_guard = queue_vec_mutex.lock().unwrap();
    // 2) 内部キューが空のときにはループする
    while queue_vec_mutex_guard.is_empty() {
      // 3) 割り込みのチェック
      if self.check_and_update_interrupted() {
        log::debug!("take: return by interrupted");
        return Err(QueueError::<E>::InterruptedError.into());
      }
      log::debug!("take: blocking start...");
      // 4) 要素が利用可能になるまで待機する
      queue_vec_mutex_guard = not_empty.wait(queue_vec_mutex_guard).unwrap();
      log::debug!("take: blocking end...");
    }
    // 5) 内部キューのpollを使って要素を取得する
    let result = queue_vec_mutex_guard.poll();
    // 6) not_fullを使って通知
    not_full.notify_one();
    result
  }

putとtakeの相互作用

putメソッドとtakeメソッドは以下の点で相互に作用する。

ブロッキングと通知: putメソッドはキューが満杯の場合にブロックし、takeメソッドはキューが空の場合にブロックする。これにより、プロデューサー（要素を追加するスレッド）とコンシューマー（要素を取り出すスレッド）は、キューの状態に応じて適切に待機または動作する
スレッド間の協調: 一方のメソッドがブロックされているスレッドを解放するために、もう一方のメソッドは条件変数を使って通知を行う。例えば、putメソッドは新しい要素を追加した後、takeメソッドで待機中のスレッドにキューに新しい要素が利用可能であることを通知する

whileをなぜ使うのか

一見不要そうなwhile文は、実はブロッキングキューのような同期処理においては非常に重要だ。これは、条件変数（Condvar）を使用する際の一般的なパターンとなる。while文を使用する理由は以下の通り：

スプリアス・ウェイクアップ(Spurious wakeup)の防止
- スレッドは何らかの理由で誤って(スプリアス・ウェイクアップと呼ばれる)目覚めることがある。while文を使用することで、スレッドが再び目覚めたときに、待機条件が依然として満たされているかを再確認する
競合状態の回避
- 複数のスレッドが同時にキューにアクセスし、条件変数によって待機が解除される場合、一つのスレッドが条件を満たして操作を行うと、他のスレッドにとってはその条件がもはや真でなくなる可能性がある。while文を用いることで、各スレッドは操作を行う前に条件を再チェックする
明確なロジック
- 条件のチェックをループ内で行うことで、コードのロジックがより明確になり、他の開発者がコードを理解しやすくなる

たとえば、putメソッドの実装において、while文はキューがフルである限り、スレッドをブロックし続ける。キューに空きができたときだけ、ループを抜けて要素の挿入を試みる。同様に、takeメソッドではキューが空である限りスレッドをブロックし、要素が利用可能になったときのみループを抜けて要素の取得を行う。したがって、while文はこれらの場合において安全性と正確性を高めるために非常に重要となる。

中断機構

ブロッキングキューでは、特定の状況で操作を中断する機能が重要だ。中断機構はputおよびtakeメソッドと密接に連携して動作する。ここでは、その中断機構の実装について詳しく見ていく。

check_and_update_interrupted

putおよびtakeメソッドで呼び出されるcheck_and_update_interruptedメソッドは、中断要求があったかどうかを判定し、その状態を更新します。もしis_interruptedフラグがtrueであれば、メソッドはtrueを返し、同時に（アトミック操作により）そのフラグをfalseに更新する。これにより、中断要求が一度だけ認識され、処理されるようになる。

queue-rs/src/queue/blocking_queue.rs at f4de43386432b0d9873af07e7cbba41e6133a75f · j5ik2o/queue-rs · GitHub

  fn check_and_update_interrupted(&self) -> bool {
    match self
      .is_interrupted
      .compare_exchange(true, false, Ordering::Relaxed, Ordering::Relaxed)
    {
      Ok(_) => true,
      Err(_) => false,
    }
  }

interrupt

interruptメソッドでは、is_interruptedフラグをtrueに設定する。これにより、putやtakeメソッドが中断される。しかし、スレッドがブロックされている場合、このフラグの設定だけでは中断は完了しません。そのため、not_emptyとnot_fullのCondvarを用いてnotify_allメソッドを呼び出し、すべてのスレッドのブロックを解除し、中断を実現する。

queue-rs/src/queue/blocking_queue.rs at f4de43386432b0d9873af07e7cbba41e6133a75f · j5ik2o/queue-rs · GitHub

  fn interrupt(&mut self) {
    log::debug!("interrupt: start...");
    self.is_interrupted.store(true, Ordering::Relaxed);
    let (_, not_full, not_empty) = &*self.underlying;
    not_empty.notify_all(); // すべてのスレッドのブロックを解除
    not_full.notify_all(); // すべてのスレッドのブロックを解除
    log::debug!("interrupt: end...");
  }

is_interrupted

is_interruptedメソッドは、外部からの中断要求があったかどうかを確認するものだ。これにより、他のメソッドが中断状態を認識し、適切に反応できるようになる。

queue-rs/src/queue/blocking_queue.rs at f4de43386432b0d9873af07e7cbba41e6133a75f · j5ik2o/queue-rs · GitHub

  fn is_interrupted(&self) -> bool {
    self.is_interrupted.load(Ordering::Relaxed)
  }

tokio版の実装

stdライブラリのMutexやCondvarなどは、リソースが利用可能になるまでスレッドを物理的にブロックする。この方法は同期処理で一般的に使用され、スレッドがリソースを待っている間は他の作業を行うことができない。これはCPUリソースを消費せず、単純な同期処理には適しているが、スケーラビリティや非同期処理の観点では効率的ではない。tokioを使った非同期処理の中でこの実装を利用するのは推奨されないので、要注意。

一方で、tokioのMutexやCondvarは非同期の待ち受けを実現する。これはスレッドを物理的にブロックするのではなく、リソースが利用可能になるまでの操作を中断し、その間に他のタスクを実行する。この方法は非同期プログラミングで一般的で、特にI/Oバウンドの処理やスケーラブルなシステムに適している。awaitキーワードを使用することで、非同期タスクの実行を「一時停止」し、リソースが利用可能になると再開する。つまるところ、stdの待ち受けはスレッドをブロックする同期的なアプローチであり、tokioの待ち受けはスレッドをブロックせずに非同期処理を行うアプローチとなる。適切な選択は、アプリケーションの要件と性能の要求によって異なる。

ということで、tokio版の実装も作った。この実装はアクターシステムを実装するときに使えそう。

あと、tokio版の実装はブロッキングしないのに、BlockingQueueという名前になっている…。AsyncBlockingQueueだろうか？それともNonBlockingQueueだろうか…。命名が難しい。

queue-rs/src/queue/tokio.rs at f4de43386432b0d9873af07e7cbba41e6133a75f · j5ik2o/queue-rs · GitHub

まとめ

Rustでブロッキングキューを実装する過程を詳細に掘り下げた。JavaのBlockingQueueを参考にしながらも、Rust独自の機能であるMutex、Condvar、およびアトミック操作を駆使して、効率的かつスレッドセーフなキューを作成できた。この実装は、Rustの同期プリミティブを活用し並行処理をモデリングする一つの方法を示した。また、JavaのBlockingQueueのコンセプトをRustに適用する試みとして、異なるプログラミング言語間のアプローチを探求する良い機会となった。

Scala 3でデータ指向プログラミングは可能か

2023-12-14T00:00:00+09:00

Scala 3におけるデータ指向プログラミング（以下DOP）について深掘りする。久々にScalaの話題を取り上げるが、これはScala Advent Calendar 2023の14日目の内容でもある。

早速だけど、DOPの基本原則は意外とシンプルだ。

コード（動作）をデータから切り離す
データを汎用的なデータ構造で表現する
データをイミュータブル（不変）として扱う
データスキーマをデータ表現から切り離す

イミュータブルなデータは採用することは多いと思うが、これをそのまま実践している人はどのくらいいるだろうか。Scalaではクラス中心の関数型プログラミングが主流だと思うし、私もそうしている。

DOPの詳細は下記の本(以下DOP本)を参照してほしい。

データ指向プログラミング

作者:Yehonathan Sharvit
翔泳社

Amazon

ちなみに留意すべき点がある。DOP本とJavaのProject Amberにおけるデータ指向プログラミングは、同じ用語を使っているが方向性が異なる。DOP本では上記の原則に重点を置いている一方で、Project Amberではデータの解釈を型で表現しモデリングのしやすさに焦点を当てている。これは多義的な用語となっているため注意が必要である。この違いは、データ指向アプローチを実践する際の重要な考慮事項である。詳細は川島さんのスライドを参照すると良い。今回の記事もDOP本のほうで書いているので注意。

さて、今回はScala 3でDOPを試みる。題材は「ショッピングカート」。中心的な集約はカート(Cart型)と注文(Order型)。

興味のある方は、OOPスタイルとDOPスタイルの両方で記述された以下のソースコードを参照してほしい。(ちなみにドメイン部分を中心にコードを書いている)

github.com

DOPを試すために、まずはご多分に漏れず「お金」オブジェクトを実装してみた。(Scala 3で実践する都合上、DOP本のまま推奨の方法で行っていない部分もありますが、そこはご容赦ください)

oop-dop-other/src/main/scala/example/j5ik2o/dop/domain/Money.scala at main · j5ik2o/oop-dop-other · GitHub

// 原則2, 3
opaque type Money = Map[String, Any]

object Money {
  final val DefaultCurrency: Currency = Currency.getInstance(Locale.getDefault)
  final val JPY: Currency = Currency.getInstance("JPY")

  def zero(currency: Currency = DefaultCurrency): Money = Money(0, currency)

  def apply(amount: BigDecimal, currency: Currency = DefaultCurrency): Money =
    Map("amount" -> amount, "currency" -> currency)

  def apply(amount: BigDecimal, currency: String): Money =
    Money(amount, Currency.getInstance(currency))

  def unapply(self: Money): Option[(BigDecimal, Currency)] =
    Some((self.amount, self.currency))

  // 原則1, 3
  extension (self: Money) {
    // 原則4
    def amount: BigDecimal = self("amount").asInstanceOf[BigDecimal]
    def currency: Currency = self("currency").asInstanceOf[Currency]

    // 二項演算子を定義。 例) val m3: Money = m1 + m2
    infix def +(other: Money): Money = {
      require(currency == other.currency)
      Money(amount + other.amount, currency)
    }
    infix def -(other: Money): Money = self + -other
    infix def *(multiplier: Int): Money = Money(amount * multiplier, currency)
    infix def *(multiplier: Double): Money = Money(amount * multiplier, currency)
    infix def /(divisor: Int): Money = Money(amount / divisor, currency)
    infix def /(divisor: Double): Money = Money(amount / divisor, currency)

    // 単項演算子を定義。 例) val m2: Money = -m1
    def unary_- : Money = Money(-amount, currency)
    
    def negated: Money = -self
    def plus(other: Money): Money = self + other
    def minus(other: Money): Money = self - other
    def times(multiplier: Int): Money = self * multiplier
    def times(multiplier: Double): Money = self * multiplier
    def divide(divisor: Int): Money = self / divisor
    def divide(divisor: Double): Money = self / divisor
  }

  // Moneyどうしの比較
  given Ordering[Money] = (x: Money, y: Money) => {
    require(x.currency == y.currency)
    x.amount.compare(y.amount)
  }

  // IntからMoneyへの暗黙的型変換。 例) val m1: Money = 100
  given Conversion[Int, Money] = (amount: Int) => Money(amount, DefaultCurrency)

}

定義側は全く見慣れない構造だが、利用側は意外と慣れ親しんだスタイルで使える。

val money1 = Money(100)
val money2 = Money(200)

val result1 = money1 + money2 // Money(300)
val result2 = money1 - money2 // Money(-100)
val result3 = money1 * 2 // Money(200)
val result4 = money1 / 2 // Money(50)

原則1 「コード(動作)をデータから切り離す」

原則1では、データ構造とメソッドを分離する。つまり、関数やメソッドを独立させるということ。

データの定義

データ型としてのMoneyはMap[String, Any]として実装されている。クラスベースだと属性と振る舞いを含めて型というイメージだが、DOPでは型はデータのみ。

opaque type Money = Map[String, Any]

もちろん、これはScala 3の固有の機能なのでDOP本に言及はなく、今回の独自の工夫をしている部分になる。opaque typeを使うことで、Map型でありながらMoneyとして型安全を保てる。間違って他の型やMap[String, Any]型の引数に渡すとコンパイルエラーになる。DOPするならこの機能は是非使いたいところ。

コードの定義

Moneyに関連するメソッド群は、拡張メソッドとして定義した。これも今回の独自の工夫と言ってよい。thisに相当する部分はメソッドの引数として渡される。実装上はselfとしている。GoやRustのメソッドに似たような記述になる。Money.plus(self, other)のようにselfを引数の取ってもよいが、左から右に流れるように読むことが難しいので拡張メソッドにした。

extension (self: Money) {
    // ...
    infix def +(other: Money): Money = {
      require(currency == other.currency)
      Money(amount + other.amount, currency) // copyメソッドは使えない…
    }
    // ...
}

amountやcurrencyもメソッドとして定義されているため、ここではあまり差分はない。

+とplusの加算メソッドの使い方として、以下はすべて同じ意味になる。

val r1 = money1 + money2
val r2 = money1.+(money2)
val r3 = Money.+(money1)(money2)

val r4 = money1.plus(money2)
val r5 = Money.plus(money1)(money2)

原則2「データを汎用的なデータ構造で表す」

コンストラクタはapplyメソッドで表現。ただのMap[String, Any]生成だ。これは柔軟性を得るためのトレードオフ。

  def apply(amount: BigDecimal, currency: Currency = DefaultCurrency): Money =
    Map("amount" -> amount, "currency" -> currency)

  def apply(amount: BigDecimal, currency: String): Money =
    Money(amount, Currency.getInstance(currency))

もちろん、値型がAnyなので型安全性が失われる。これは具体的な値型を使うクラスの場合と違って値を取り扱う場合に注意が必要になる。 DOP的な柔軟性が下がるが型安全性が気になる場合は、構造体的なcase classでもいいのではないか。

原則3 「データをイミュータブル(不変)として扱う」

Scalaではミュータブルなデータ構造を避けるだけで、この原則は容易に実現できる。Moneyのメソッド群も不変。

原則4 「データスキーマをデータ表現から切り離す」

原則4 「データスキーマをデータ表現から切り離す」は、データとデータスキーマを分離する考え方。

一つには、フィールドアクセス用の専用メソッドがある意味データスキーマになっている。

extension (self: Money) {
  // ...
  def amount: BigDecimal = self("amount").asInstanceOf[BigDecimal]
  def currency: Currency = self("currency").asInstanceOf[Currency]
  // ...
}

ところで、サブタイプの表現はDOPではどう扱うか。DOPでは継承を利用しないため、サブタイプごとのデータ型だけが存在することになる。

しかし、Scalaの場合、このアプローチに固執する必要はないだろう。sealed traitや型クラスを利用すれば良いのではないか。今回の取り組みはあくまで実験的なものである。

Cartに含める商品にはダウンロード型のコンテンツ(DownloadableItem)や車(CarItem)やそれ以外の商品(GenericItem)がある。それらの共通項を括りだしたのがItem型になる。

oop-dop-other/src/main/scala/example/j5ik2o/dop/domain/Item.scala at main · j5ik2o/oop-dop-other · GitHub

package example.j5ik2o.dop.domain

import example.j5ik2o.common.domain.ItemType

import java.net.URL

opaque type Item   = Map[String, Any]
opaque type ItemId = String

object ItemId {
  def apply(value: String): ItemId          = value
  def unapply(self: ItemId): Option[String] = Some(self)

  given Conversion[String, ItemId] = ItemId(_)

  extension (self: ItemId) {
    def value: String = self
  }
}

object Item {

  def apply(id: ItemId, name: ItemName, price: Money, itemType: ItemType): Item =
    Map("id" -> id, "name" -> name, "price" -> price, "type" -> itemType)

  extension (self: Item) {
    def id: ItemId         = self("id").asInstanceOf[ItemId]
    def name: ItemName     = self("name").asInstanceOf[ItemName]
    def price: Money       = self("price").asInstanceOf[Money]
    def itemType: ItemType = self("type").asInstanceOf[ItemType]
  }

}

opaque type GenericItem = Map[String, Any]

object GenericItem {

  def apply(id: ItemId, name: ItemName, price: Money): GenericItem =
    Item.apply(id, name, price, ItemType.Generic)

  def unapply(self: GenericItem): Option[(ItemId, ItemName, Money)] =
    Some((Item.id(self), Item.name(self), Item.price(self)))

  extension (self: GenericItem) {
    def id: ItemId = Item.id(self)
    def name: ItemName = Item.name(self)
    def price: Money = Item.price(self)
  }

  given Conversion[GenericItem, Item] = _.asInstanceOf[Item]

}

opaque type DownloadableItem = Map[String, Any]

object DownloadableItem {

  def apply(id: ItemId, name: ItemName, url: URL, price: Money): DownloadableItem =
    Item.apply(id, name, price, ItemType.Download) + ("url" -> url)

  def unapply(self: DownloadableItem): Option[(ItemId, ItemName, URL, Money)] =
    Some(
      (
        Item.id(self),
        Item.name(self),
        self.url,
        Item.price(self)
      )
    )

  given Conversion[DownloadableItem, Item] = _.asInstanceOf[Item]

  extension (self: DownloadableItem) {
    def id: ItemId = Item.id(self)
    def name: ItemName = Item.name(self)
    def url: URL = self("url").asInstanceOf[URL]
    def price: Money = Item.price(self)
  }
}

opaque type CarItem = Map[String, Any]

object CarItem {

  def apply(id: ItemId, name: ItemName, price: Money): CarItem =
    Item.apply(id, name, price, ItemType.Car)

  def unapply(self: CarItem): Option[(ItemId, ItemName, Money)] =
    Some((Item.id(self), Item.name(self), Item.price(self)))

  given Conversion[CarItem, Item] = _.asInstanceOf[Item]
}

共通処理を行いたい場合、各型を共通のItem型に変換する。

val genericItem: GenericItem = GenericItem("1", "name", 100)
assert(genericItem.id.value == "1")
val item: Item = genericItem
assert(item.id.value == "1")

暗黙的型変換により、GenericItemをItemに変換できる。本質的にはMapなので、単なるキャストに過ぎない。

given Conversion[GenericItem, Item] = _.asInstanceOf[Item]

抽象型に相当するItemのメソッドは、GenericItemに対しても呼び出せる。ただ、これは実装がやや面倒な側面がある。ちなみに、ItemのメソッドにGenericItemのselfを渡しているが暗黙的型変換でItemに変換されているので、問題なくコンパイル可能となっている。

extension (self: GenericItem) {
  def id: ItemId     = Item.id(self)
  def name: ItemName = Item.name(self)
  def price: Money   = Item.price(self)
}

他にもurlを持つDownloadableItemのデータを必要に応じてItem型で利用する部分があるが、検証すべきデータを自由に選択できるので確かに柔軟性が高いかもしれない。

Cart型, Order型

次はCartを実装。Moneyと同じスタイルで可能。

oop-dop-other/src/main/scala/example/j5ik2o/dop/domain/Cart.scala at main · j5ik2o/oop-dop-other · GitHub

CartIdもopaque typeで文字列型。applyメソッドで検証を行う。

copyメソッドが使えないが、Mapの+でcopyメソッド相当のことができる。

Order型も問題なく実装できた。¹

oop-dop-other/src/main/scala/example/j5ik2o/dop/domain/Order.scala at main · j5ik2o/oop-dop-other · GitHub

ざっと実装コードを眺めるとやはりGo, Rustのような雰囲気がでてくる。面白い。

まとめ

Scala 3の機能を活用し、DOPの概念とその実装方法について深く掘り下げた結果、いくつかの重要な洞察を得た。

DOPの原則には現代のプログラミングにとって有益な考え方が多く含まれている。また、Scala 3でのDOP実践においてはopaque typeなどの新機能がかなり役に立った。もはや必須機能！これにより、型安全性を維持しながらも、より柔軟で表現力に富んだデータモデリングが実現可能となる。このアプローチはOOPの一部の制約を超越し、データとその操作の明確な分離を可能にする。OOP上に組み込むとクラスを使わないので、ある意味新しいプログラミングスタイルに見える。

しかし、今回紹介したコードスタイルはOOPの標準的なスタイルと異なるため、人によっては慣れるまでに時間がかかるかもしれない。さらにDOPがその言語の設計思想にあっているかよく考える必要がある。驚きが最小にならないことも…。Scalaの場合でも無理にこのようなスタイルを採用する必要性はないと思われる。もちろん、DOPを部分的導入する考え方もあるが、やはりClojureのようなDOPに向いた言語の使用も検討する価値があると感じられる…。

いずれにしても、Scala 3の強力な表現力と型安全性を上手く活用することで、DOPスタイルでもScalaが有用であることがわかった。

付録

DOP本のソースコードはこちら。本書掲載のコード以外にchallenges以下に他の言語での実装例もある。異世界を探検したい人は覗いてみるといいかも。

github.com

Order#adjustPriceがクソコード臭がしてなんともいえないが、別の機会にDOPのリファクタリングについて書く際の題材にする予定。あしからず…。↩

RustでProperty-based testing ライブラリを実装してみた

2022-12-12T16:58:55+09:00

この記事はRust Advent Calendar 2022 - Qiitaの12日目の記事です。

以前、Rustの実装力をあげるために、Property-based testingライブラリを作ったのですが、それについて説明する記事です。

Property-based testingとは

Property-based testingとは何か。詳しくは以下を参照してください。

jessitron.com

Property-based tests make statements about the output of your code based on the input, and these statements are verified for many different possible inputs.

statementsはDSLのことかなと理解していますが、がくぞさんの説明のほうが簡潔なので以下の資料も参考にしてみてください。

テストデータをランダムに半自動生成して、その生成された全ての値について、満たすべき性質を満たしているかテストする

gakuzzzz.github.io

実装はしたくない使いたいという人はこっち

なんでもかんでも作ればいいってわけではないので、crates.ioから検索すると以下が代表的なクレートです。

実用ならこっちのほうがいいかも。

今回は実装力を上げるために車輪を再実装します。

実装したクレートについて

これです。

github.com

コード量はそんなにないので、さらっと読めるかも。

なにがうれしいのか

URIパーサを実装したときに、このクレートを使ってテストを書きました。以下のようなものです。 absolute_uri関数やuri関数がURIパーサーです。その関数をテストしています。

  #[test]
  fn test_uri() -> Result<()> {
    let mut counter = 0;
    let uri_gen = uri_gen(); // テストデータを生成するジェネレータ
    // Property-based testingを行うPropを生成する
    let prop = prop::for_all_gen(uri_gen, move |s| {
      counter += 1;
      log::debug!("{:>03}, uri:string = {}", counter, s);
      let input = s.as_bytes();
      let uri = (uri() - end()).parse(input).success().unwrap();
      log::debug!("{:>03}, uri:object = {:?}", counter, uri);
      assert_eq!(uri.to_string(), s);
      true
    });
    // Property-based testingの実行
    prop::test_with_prop(prop, 5, TEST_COUNT, RNG::new())
  }

https://github.com/j5ik2o/oni-comb-rs/blob/9b9a465e8ab098e8fae18c0121f27fcf6b53cf0a/uri/src/parsers/uri_parsers.rs#L73

テストではuri_gen関数が利用されます。これはURIの仕様に沿った文字列をランダムに生成するジェネレータ(Gen)です。uri_gen関数はscheme_gen関数やquery_gen関数やfragment_gen関数によって実装されます。Genどうしを合成したGenが作れます。

他のケースとして、IPv6アドレスのパーサーのテストとかもあります。これはまぁまぁ面倒で、こういうのは手でテストデータを作りたくないですね。

https://github.com/j5ik2o/oni-comb-rs/blob/43484e77f885ea4f48bbb893de9afc3c13e44959/uri/src/parsers/ip_v6_address_parsers.rs#L201

このような手法を使わずに自前でテストデータを作るのは骨が折れます。原始的なGenを使って高度なGenを組み上げるスタイルで、Property based testingのライブラリを使うと割と楽ができます。

Genの利用方法

もうちょっと実装よりのGenの利用方法について。

なんらかの方法でGenを生成(後述します)しfor_all_gen関数に第一引数に渡して、第二引数の関数でGenによって生成された値を使います(この関数の戻り値がfalseを返した場合はProperty based testingが失敗します)。第二引数で与えた関数はテスト実行時に指定されたテスト回数分呼び出されます。すべてのテストにおいて戻り値がtrueでないとテストは成功と見なされません。

そして、for_all_gen関数はPropを生成するので、それをtest_with_prop関数を渡すとテストを実行します。テストの実行にはProp以外にテストサイズ、テスト数、乱数生成器を指定する必要があります。

let gen = ...
let prop = for_all_gen(gen, move |input| {
  // テストコード
  true
});
let result = test_with_prop(prop, 5, TEST_COUNT, RNG::new());

参考にした実装

この記事では詳しく説明しませんが、FP in Scalaのfirst-edtionのコードを参考にしました。

github.com

興味がある方は、日本語の書籍もあるので読んでみてください。

Scala関数型デザイン&プログラミング ―Scalazコントリビューターによる関数型徹底ガイド (impress top gear)

作者:Paul Chiusano,Rúnar Bjarnason
インプレス

Amazon

実装コード

主な実装を説明します。

for_all_gen関数とtest_with_prop関数

for_all_gen関数はGenを基にPropを生成する関数です。

pub fn for_all_gen<A, F>(g: Gen<A>, mut test: F) -> Prop
where
  F: FnMut(A) -> bool + 'static,
  A: Clone + Debug + 'static, {
  Prop {
    run_f: Rc::new(RefCell::new(move |_, n, rng| {
      let success_counter = itertools::iterate(1, |&i| i + 1).into_iter();
      random_stream(g.clone(), rng)
        .zip(success_counter)
        .take(n as usize)
        .map(|(test_value, success_count)| {
          if test(test_value.clone()) {
            PropResult::Passed { test_cases: n }
          } else {
            PropResult::Falsified {
              failure: format!("{:?}", test_value),
              successes: success_count,
            }
          }
        })
        .find(move |e| e.is_falsified())
        .unwrap_or(PropResult::Passed { test_cases: n })
    })),
  }
}

https://github.com/j5ik2o/prop-check-rs/blob/4776da568ca35ca319e66c866d9670ce7c9fe40f/src/prop.rs#L149

PropはFnMutを内包する構造体です。メソッドはそのFnMutを実行するrunがあります。他にもPropとPropを合成するandメソッドがあったりします。

pub struct Prop {
  run_f: Rc<RefCell<dyn FnMut(MaxSize, TestCases, RNG) -> PropResult>>,
}

prop-check-rs/prop.rs at 4776da568ca35ca319e66c866d9670ce7c9fe40f · j5ik2o/prop-check-rs · GitHub

for_all_gen関数では、Genを実行できる無限ストリームを生成し、そのGenから生成された値を引数として渡し、指定されたテスト関数に指定回数分呼び出すPropを生成します。

test_with_propはテスト条件を指定して、Propを実行するだけです。

GenとGenを生成するファクトリGens

Genを実行する仕組みがわかったところで、Gen自体をどうやって生成するかについて簡単に説明します。

その前にGenの定義から。 GenはState型を内包する型です。RNGは純粋な乱数生成器です。

pub struct Gen<A> {
  sample: State<RNG, A>,
}

https://github.com/j5ik2o/prop-check-rs/blob/4776da568ca35ca319e66c866d9670ce7c9fe40f/src/gen.rs#L354

State型はいわゆるStateモナドのような実装になっていて、Stateどうしを合成して新たなStateを生成することができます。そして、それを使うGenもGenどうしを合成可能です。

Gens#pure

GensはGenのファクトリメソッドが定義されています。

最も単純なメソッドはpure関数でしょう。何度呼び出してもpureの引数に与えた値しか返さないGenを生成できます。

let gen = Gens::pure(1);
let prop = for_all_gen(gen, move |input| {
  input == 1 // inputは常に1
});
let result = test_with_prop(prop, 5, TEST_COUNT, RNG::new());

やっていることは単純にrunされたときに実行される関数内で固定値を返すようにします。

  pub fn pure<B>(value: B) -> Gen<B>
  where
    B: Clone + 'static, {
    Gen::<B>::new(State::value(value))
  }

https://github.com/j5ik2o/prop-check-rs/blob/4776da568ca35ca319e66c866d9670ce7c9fe40f/src/gen.rs#L27

Gens#one_char

one_char関数は任意のcharを返します。他にもone_u8, one_u32, ...など型に応じたメソッドがあります。ジェネリック版のoneメソッドもあります。

let gen = Gens::one_char();
let prop = for_all_gen(gen, move |input| {
  println!("input = {}", input.to_string()); // 任意の文字
  true
});
let result = test_with_prop(prop, 5, TEST_COUNT, RNG::new());

prop-check-rs/rng.rs at 4776da568ca35ca319e66c866d9670ce7c9fe40f · j5ik2o/prop-check-rs · GitHub

やっていることは単純にrunされたときに実行される関数内でRNGから任意の値を取っているだけです。

Gens#list_of_n

このファクトリメソッドは任意の数値の配列を生成できるGenが欲しい場合に使えます。以下のようにすると、任意のu8を5個保持するVecを返すGenを生成できます。

let gen = Gens::list_of_n(5, Gens::one_u8());
let prop = for_all_gen(gen, move |input| {
  println!("input = {:?}", input); // 任意の文字の配列
  true
});
let result = test_with_prop(prop, 5, TEST_COUNT, RNG::new());

複数の、Gen#sampleを返す関数を保持するVecを素に作ったStateをGenに組み込むことで、複数の値を生成して返せるようになります。

  pub fn list_of_n<B>(n: usize, gen: Gen<B>) -> Gen<Vec<B>>
  where
    B: Clone + 'static, {
    let mut v: Vec<State<RNG, B>> = Vec::with_capacity(n);
    v.resize_with(n, move || gen.clone().sample);
    Gen {
      sample: State::sequence(v),
    }
  }

https://github.com/j5ik2o/prop-check-rs/blob/4776da568ca35ca319e66c866d9670ce7c9fe40f/src/gen.rs#L93

Gens#choose

特定の値の範囲から一つの値を選択する場合は、chooseが使えます。以下のようにすると、1から10までの値を一つ選択するGenを生成できます。

let gen = Gens::choose(1, 10);
let prop = for_all_gen(gen, move |input| {
  println!("input = {}", input); // 1から10までの任意の数値
  true
});
let result = test_with_prop(prop, 5, TEST_COUNT, RNG::new());

map関数の中で、生成された乱数を素に、与えられた最小・最大の範囲から対応する数値を選ぶようにしています。

  pub fn choose_u32(min: u32, max: u32) -> Gen<u32> {
    Gen {
      sample: State::<RNG, u32>::new(move |rng: RNG| rng.next_u32()),
    }
    .map(move |n| min + n % (max - min + 1))
  }

https://github.com/j5ik2o/prop-check-rs/blob/4776da568ca35ca319e66c866d9670ce7c9fe40f/src/gen.rs#L259

Gens#one_of

chooseを使うと引数で与えた複数のGenから一つ選ぶone_ofも実装できます。

let gen = Gens::one_of(vec![Gens::choose(1, 10), Gens::choose(90, 100)]);
let prop = for_all_gen(gen, move |input| {
  println!("input = {}", input); // 1から10までもしくは90から100までの任意の数値
  true
});
let result = test_with_prop(prop, 5, TEST_COUNT, RNG::new());

これもシンプル。コレクションのインデックスをchooseで選ぶ。そのインデックスを使ってVecからGenを取得して返すだけ。

  pub fn one_of<T: Choose + Clone + 'static>(values: impl IntoIterator<Item = Gen<T>>) -> Gen<T> {
    let mut vec = vec![];
    vec.extend(values.into_iter());
    Self::choose(0usize, vec.len() - 1).flat_map(move |idx| vec[idx as usize].clone())
  }

prop-check-rs/gen.rs at 4776da568ca35ca319e66c866d9670ce7c9fe40f · j5ik2o/prop-check-rs · GitHub

Gens#frequency

出現比率を指定できるfrequencyもあります。比率を表す数値とGenのタプルの配列かVecを引数に指定できます。

let gens = [
      (3, Gens::choose_u32(1, 10)),
      (2, Gens::choose_u32(50, 100)),
      (5, Gens::choose_u32(200, 300)),
    ];
let gen = Gens::frequency(gens);
let prop = for_all_gen(gen, move |input| {
  println!("input = {}", input); // 1〜10 or 50〜100 or 200から300の任意の数値が指定された出現比率で得られる
  true
});
let result = test_with_prop(prop, 5, TEST_COUNT, RNG::new());

GenをBTreeMapに格納して、生成された乱数でキーを指定し、対応するGenを引き当てているだけです。

  pub fn frequency<B>(values: impl IntoIterator<Item = (u32, Gen<B>)>) -> Gen<B>
  where
    B: Debug + Clone + 'static, {
    let filtered = values.into_iter().filter(|kv| kv.0 > 0).collect::<Vec<_>>();
    let (tree, total) = filtered
      .into_iter()
      .fold((BTreeMap::new(), 0), |(mut tree, total), (weight, value)| {
        let t = total + weight;
        tree.insert(t, value.clone());
        (tree, t)
      });
    Self::choose_u32(1, total).flat_map(move |n| tree.range(n..).into_iter().next().unwrap().1.clone())
  }

https://github.com/j5ik2o/prop-check-rs/blob/4776da568ca35ca319e66c866d9670ce7c9fe40f/src/gen.rs#L77

まとめ

あまり良い方法だと思いませんが、構造体に参照を持ち込むとどうしてもロジックが複雑になってしまうので、dyn FnをRcでラップしClone可能にしました。ほかに代替のよい方法があればよいのですが…。

pub struct State<S, A> {
  pub(crate) run_f: Rc<dyn Fn(S) -> (A, S)>,
}

impl<S, A> Clone for State<S, A>
where
  S: 'static,
  A: Clone + 'static,
{
  fn clone(&self) -> Self {
    Self {
      run_f: self.run_f.clone(),
    }
  }
}

ということでご参考になれば幸いです。

メモ:値オブジェクトの定義と差異について

2022-05-22T20:45:35+09:00

「値オブジェクト」の定義について不勉強だったので「DDDの値オブジェクト」の定義とDDD以外の「値オブジェクト」との違いについて、改めて関連書籍を読み直し整理してみました。

すごい長いし細かいので他人に読ませるような記事ではなく、自分のために書いたメモです。

もし読むなら興味がある人だけで。

自分向けのメモですが、一応この記事の前提や意図を書いておきます。

「DDDの値オブジェクト」以外を否定する記事ではありません。
原理主義のように書籍の理想どおり実践するべきだと主張するつもりはありません
- 「理想に従えばよい」「理想に従うの無意味だ」と決め付けの二項対立的な思考ではなく、理想と現実の絡み合ったグレーゾーンを見極めつつ、現場で手を打つのが優れた実践者ではないでしょうか
下記に紹介する、それぞれの値オブジェクトの優劣について細かく議論し、論破する・されることを目的としていません。
言い訳と聞こえるかもしれませんが、読書に完璧はありません。そしてその感想にはたぶんにバイアスがかかります
- 読書というのは同じ書籍を十人が読めば十人とも同じ解釈になるとは限らないですし、読書の解釈は「ここの部分の解釈は、これで合っていますか？」と著者に聞くことも難しいのです
- だからといって、いい加減に読んでもよいとは考えていません。13年以上現場でDDDを実践し*1、DDD本和訳レビューや他のDDD本のレビューも関わり、著者のEvansからも直接講義を受け、他の有識者を含む日本のDDDコミュニティの方々と対話してきた経験からも考えをまとめています
- いずれにしても、そもそも完璧な読書など存在しないという前提で、この記事を読んでいただけると嬉しいです
僕の見解が唯一正しいなどと考えていませんし、DDDだけが正しい設計方法だと考えていません。ぜひ他の方の意見も参考にしてみてください。当然、私の解釈が間違っている可能性もあります。そのときは何か根拠付きで指摘していただけると有意義だと思います

5/23追記

"ドメインモデル（ドメインオブジェクト）"という表記に問題をあると…。これだけで問題になるのですね。

その記述の上の方に"ドメインモデルの考え方を反映した実装がドメインオブジェクト"と書いてますが…。

こういう重箱の隅をつつかれても不毛ですね…

前置きが長くなりましたが、値オブジェクトはよく話題になるものは、大きくわけて3つあると思うので、それをみていきましょう。

Wikipediaの値オブジェクト

さて、Wikipediaによると、Value Object(値オブジェクト)は以下のように説明されている。この定義を「Wikipediaの値オブジェクト」と呼ぶことにします。

コンピュータサイエンスでは、Value Object(値オブジェクト)は、同等性がアイデンティティに基づいていない単純なエンティティを表す小さなオブジェクトである。つまり、2つの値オブジェクトは、同じ値を持つ場合は等しく、必ずしもそれらが同一のオブジェクトである必要はない。

Value object - Wikipedia

PofEAAの値オブジェクト

Martin Fowler 著『エンタープライズアプリケーションアーキテクチャパターン』(PofEAA)によると

https://www.amazon.co.jp/dp/B01B5MX2O2

IDに基づいた等価性を確保していない、MoneyやDateRangeなどのシンプルな小型オブジェクト。

さまざまな種類のオブジェクトシステムを使うとき、参照オブジェクトと値オブジェクトの相違が役立つことに気づいた。これら2つのオブジェクトではバリューオブジェクトの方が小型であり、純粋にオブジェクト指向ではない多くの言語にあるプリミティブな型に類似している。

マーチン・ファウラー. エンタープライズアプリケーションアーキテクチャパターン (Japanese Edition) (Kindle の位置No.12687-12690). Kindle 版.

「IDに基づいた等価性を確保していない小型のオブジェクト」という定義になる。

「PofEAAの値オブジェクト」にDTOは含まれるか

論争になりやすいのはDTOの概念が含まれるかという点。

Data Transfer Object - Wikipedia

DTOとは自身のデータへの格納と取り出し機能しか持たないオブジェクトのことです。JavaではSetter,Getterなどで構成されるオブジェクトで、主にデータ転送の目的で利用されます。例えばJSON形式のリクエストやレスポンスはDTOとして設計することが多いのではないでしょうか。

このWikipediaによると「PofEAAの値オブジェクト」はDTOとは異なるらしい。 理由は書いてないのでよくわかりません。

bliki: ValueObject

しかし、こちらの別の記事によると、過去に、特定のコミュニティ(J2EE？)ではDTOも「値オブジェクト」として用いられていたらしい。

実践DDD本第6章「値オブジェクト」～振る舞いを持つ不変オブジェクト～

こちらのFowlerのブログでも、過去にJ2EEの文献がDTOをVOに分類していたが、今はみなくなった、と言及があります。

One source of terminological confusion is that around the turn of the century some J2EE literature used "value object" for Data Transfer Object. That usage has mostly disappeared by now, but you might run into it.

用語の混乱の原因の1つは、世紀の変わり目の頃、いくつかのJ2EE文献がData Transfer Objectに対して "value object "を使っていたことです。このような使い方は今ではほとんどなくなりましたが、遭遇することがあるかもしれません。

というわけで、今は「PofEAAの値オブジェクト」にDTOの概念が含まれないと判断するのが妥当でしょう。 ~~(WikipediaのほうはDTOの概念は含まれるだろうか…判断が付かない…)~~

追記: 5/23

WikipediaのDTOの解説によるとDTOは含まれないそうだ。

https://twitter.com/justinto_nation/status/1528561673061117953

「IDに基づいた等価性を確保していない」以外の特徴はあるのか

上記の定義以外はどう解釈すべきか…。「18.7 マネー」あたりです。パターンではなく実装例の解説なので判断が難しい。

個人的にはこれらの特徴も定義に含めたいが、人によって意見が分かれるところかもしれません。

18.7 マネー

コンピュータはMoney（貨幣）を処理しているが、困ったことに主流のプログラミング言語はどれもMoneyを最重要データ型として扱っていない。通貨を扱う環境にとって、型がないことが問題の原因であることは明らかである。

マーチン・ファウラー. エンタープライズアプリケーションアーキテクチャパターン (Japanese Edition) (Kindle の位置No.12754-12756). Kindle 版.

「PofEAAの値オブジェクト」は対象の問題を解決する型(ドメインモデル)だ、という見方もできそうです。

Moneyの場合、Moneyオブジェクトを数字のように簡単に使えるような、算術演算が必要である。しかし、Moneyの算術演算と数字のMoney演算との間には、重要な相違点がいくつかある。最も明確なのは、異なる貨幣単位の金銭を合算しようとする場合、加算や減算では常に貨幣単位を認識する必要があることである。シンプルでよく使われる対処方法は、異なる貨幣単位の合算をエラーとして処理することである。

マーチン・ファウラー. エンタープライズアプリケーションアーキテクチャパターン (Japanese Edition) (Kindle の位置No.12772-12776). Kindle 版.

異なる貨幣単位を無視して合算できてしまうと、Money型として不変条件(invariant)が維持できない。そうなると値としての存在意義や利用価値を失うので、値オブジェクトのメソッドによって保護するような記述と読める。

これらはそう読めるだけで「PofEAAの値オブジェクト」としてそうするべきなのかわからない。

「PofEAAの値オブジェクト」に「DDDの値オブジェクト」は含まれるか

先ほど紹介したブログによると、Vaughn VernonがDDDの観点から値オブジェクトを解説しているとのこと。

Vaughn Vernon's description is probably the best in-depth discussion of value objects from a DDD perspective. He covers how to decide between values and entities, implementation tips, and the techniques for persisting value objects.

Vaughn Vernonの記述は、おそらくDDDの観点から見た値オブジェクトの最も深い議論である。彼は、値とエンティティの間の決定方法、実装のヒント、および値オブジェクトを永続化するためのテクニックをカバーしています。

「Vaughn Vernonの記述」とは『実践ドメイン駆動設計』(Vaughn Vernon)で書かれた値オブジェクトの説明のことでしょう。つまり「DDDの値オブジェクト」のことです。「DDD観点からみた値オブジェクト」としていますが、「PofEAAの値オブジェクト」に「DDDの値オブジェクト」が含まれるかはこの文章からははっきりしない。

DDDの値オブジェクト

下のほうで例示している、複数のDDD関連書籍を改めて読み直しました。

【「DDDの値オブジェクト」はドメインオブジェクトである】は、様々なDDDの関連書籍にも明確に書かれているので、これは間違いでしょう。DDDに詳しい人にとっては当たり前のことですが。

WikipediaやPofEAAの立場からみると、ドメイン・非ドメインどちらでも使える値オブジェクトが、なぜドメイン限定になるんだ。なぜ値オブジェクトがドメインモデル（ドメインオブジェクト）だといいきるのだ、という印象を持たれるかもしれません。

まぁそれが差異です。混ぜて考えると、ゴチャゴチャになります。

(この辺りの話はDDDの汎用サブドメインのトピックも関係しますが、また今度にします…)

「DDDの値オブジェクト」の特徴

以下は、DDD関連書籍に記述されている事実から抽出した「DDDの値オブジェクト」の主な特徴です。凝集度を高めるや自己文書化など、他にも挙げだしたらキリがないのでこんなところだと思います。

ドメイン内の何かしらの計測・定量化・説明のいずれかを扱う
値が等しいかどうかを、他と比較できる(値が等しいかどうかを、他と比較できる)
状態を不変(immutable)に保つこと(が望ましい)
計測値や説明が変わったときに、全体を完全に置き換えられる
関連する属性を不可欠な単位として組み合わせ、概念的な統一体を形成する
協力関係にあるその他の概念に「副作用のない関数(SIDE-EFFECT-FREE-FUNCTIONS)」を提供する
- ここでいう関数とは、副作用がない振る舞いやメソッドのこと
- パターン名としては”副作用のない”は強調されているが、不変(immutable)であれば振る舞いに副作用がないのは自然なこと
- メソッド名はユビキタス言語で表現されるドメインの概念と対応付く
- DTOのようなインターフェイスは意図していない
ドメイン上の制約に基づき不変条件(invariant)を表明する(ASSERTIONS)

これらを定義どおり実践するのか。それは時と場合によるとしか言えません。書いてあることは難しい印象がありますが、実際には最近のプログラミング言語に慣れているなら、それほど苦労せず実践できると思います。

特徴の比較

いずれの値オブジェクトも以下が共通する特徴。最初からわかりきってたと思いますが…。

2) 値が等しいかどうかを、他と比較できる (IDではなく値による等価性を確保)
3) 状態を不変(immutable)に保つこと(が望ましい)

「Wikipedia及びPofEAAの値オブジェクト」はドメイン・非ドメインに関係なく使えそうです。

「DDDの値オブジェクト」はDDD特有の事情が含まれています。

明確に差異がある。

差異の解釈

差異を明確にする立場であれば、同じところは2)3)だけで他の項目は違うと言えばいい。確かに用語の定義としてはそうかもしれません。でも、そう簡単な話ではないような気がします。

そもそも、他の項目はDDD固有の考え方なのか、という疑問あるかもしれません。たとえば「必要に応じて振る舞いも作るし不変条件も表明するだろ、わざわざDDD文脈を付けるのは意味不明」という意見もあるかもしれません。WikipediaやPofEAAに明確な定義がなくても、オブジェクトならこういうやりかたをするよね、みたいな常識はあるかもしれません。

少し話しは逸れますが、そのソフトウェアの存在意義に関わる関心のことをドメインと呼ぶ*2ので、その関心とそれ以外を分けて考える、ある意味概念に境界線を引くために使う方法論がDDDだと理解しています*3。

元々ドメインという用語はEvans独自の用語ではありません*4し、DDDのようなある種の形式的な手法*5に頼らずとも、暗黙的にドメインを見出しそれを解決するモデルを作れる人は少ないですがいます*6。そういう人にはDDDの手法が回りくどく感じるかもしれません。そうであればもはやDDDのよう手法に頼る必要もないでしょう。本質的には、目的の結果が得られる、適切な方法論ならいずれでもよいでしょう。

一方で、そのように誰もが問題を解決できるのであれば、DDDはこれほどに注目されないと思います。複雑な問題では概念に境界線を引くのは思った以上に難しいものです。簡単に線引きできるなら、人類はモジュールやマイクロサービスの分割点で悩んだりしません。そういうときに、DDDがツールとして選択肢の一つになります。もちろん、DDDは銀の弾丸ではないので結果がうまく行く保証はありません。それでも我々はよりよい結果のために工夫をしながらツールも使うのではないでしょうか。

というわけで、この両方の視点で考えると「DDDの観点がないから劣っている」とか「DDDは形式的だから過剰」だとか、一概に言えません。そういう意味では、実用上、例に挙げた値オブジェクトに大きな差異があるとも言い切れないのです。

個人的には、チームで機能させられるのはどちらかというとDDDの方だと思いますが、個人の裁量が大きい仕事ではそこまで形式的な方法に頼る必然性もなかったりするので、時と場合によって思考停止せずにどの選択肢がよいか考えたほうがよさそうです。

まとめ

と、ここで終わるのはよくないですね。

少なくとも「目的が違うものを混ぜて語るな。文脈を分けろ」という指摘があるとしたら、ごもっともです。思いのほか「値オブジェクト」は多義的だったので、用語の使い方としては文脈をわきまえるしかなさそうです。

今回はこういった文脈を前置きせずに議論してしまったところがあるので、そこは配慮が足りなかったと思っています。なので、自戒を込めて今後は文脈を共有できない場では「DDDの値オブジェクト」などとプレフィクスを付けて、他と異なる概念として語るとよさそうです。

近年、DDD関連図書が増えたこともあり「DDDの値オブジェクト」の概念はよく耳にしていて半ば常識になりつつあると思います。ですが、視野が狭くならないように「値オブジェクト」としては解釈が複数あることを必要に応じて啓蒙していくのがよさそうです。

長々と最後まで読んでいただき、ありがとうございました。

追加資料

DDDの値オブジェクトの定義はどうなっているか、Evans本及びDDD関連書籍から関係しそうな箇所を以下に列挙。細かすぎるので自分用のメモぐらいのつもりで書いています。読まなくてもよいと思います。

『エリック・エヴァンスのドメイン駆動設計』

著 Eric Evans(@ericevans0)

https://www.amazon.co.jp/dp/B00GRKD6XU

私は和訳版のレビューに参加しました。

補足: 大前提であるドメインと境界づけられたコンテキストについて

第1部ドメインモデルを機能させる

すべてのソフトウェアプログラムは、それを使用するユーザの何らかの活動や関心と関係がある。ユーザがプログラムを適用するこの対象領域が、ソフトウェアのドメインである。ドメインの中には、物理的な世界を含んでいるものもある。例えば、航空会社の予約プログラムのドメインは、実際の航空機に搭乗する現実の人々を含んでいる。一方、実体を含まないドメインもある。会計プログラムのドメインは金銭と財務である。ソフトウェアのドメインは、コンピュータとほとんど関係ないのが普通だが、例外もある。ソースコード管理システムのドメインは、ソフトウェア開発そのものである。

Eric Evans. エリック・エヴァンスのドメイン駆動設計 (Japanese Edition) (p.2). Kindle 版.

補足

ドメインとは何か。ソフトウェアプログラムを使用するユーザ(利用者や利害関係者)の何らかの活動や関心に関係あり、ユーザがプログラムを適用する対象領域がドメインである。コンピュータとほとんど関係ないが、例外もあるとしている。つまり、ソフトウェアと関係するものもある。

ソフトウェアを利用するユーザの活動や関心がドメイン。問題領域もしくは問題ドメインと呼ばれることがある。広義には開発者にとってのドメイン(言語・処理系やSQLやHTTPやWeb F/Wなど)もある、と読める。

たとえば、バージョン管理という問題ドメインに対する、GitのBlob, Tree, Commit, Tagなどは実際は解決ドメイン(後述)のモデルにあたるだろうが、日常的には問題ドメインと解決ドメインを明確に区別しないで語ることが多い。詳しくは以下のツイートを参照

かとじゅん on Twitter: "https://t.co/wMRnW9hQXB杉本さんのこの図とてもわかりやすい。ドメインモデルはソリューションのモデル。その実装はドメインオブジェクト。BC毎に個別に紐付くもの。なので、Gitのコミットモデル、Subversionのコミットモデルになる。 pic.twitter.com/KFBs6NLB3c / Twitter"

第4部戦略的設計

第14章モデルの整合性を維持する

境界づけられたコンテキスト(BOUNDED CONTEXT)

モデルが適用されるコンテキストを明示的に定義すること。明示的な境界は、チーム編成、そのアプリケーションに特有の部分が持つ用途、コードベースやデータベーススキーマなどの物理的な表現などの観点から設定すること。その境界内では、モデルを厳密に一貫性のあるものに保つこと。ただし、境界の外部の問題によって注意を逸らされたり、混乱させられたりするのを避けること。境界づけられたコンテキストは、特定のモデルが適用できる範囲を制限する。

Eric Evans. エリック・エヴァンスのドメイン駆動設計 (Japanese Edition) (p.344). Kindle 版.

補足

境界づけられたコンテキストとは何か。ドメイン、ユーザの活動や関心に対応してソフトウェアで解決する領域のことである。解決ドメインと言われることもある。通常、ソースコード上でドメインモデルやドメインオブジェクトといっているものはこちらに分類される、ソリューションとしてのモデル。

第2部モデル駆動設計の構成要素

優れたドメインモデルを開発することは芸術である。しかし、モデルの個々の要素を実際に設計し、実装することは、比較的体系立てて行える。ドメインの設計を、ソフトウェアシステムにおけるその他の大量の関心事から分離することで、設計とモデルとのつながりが非常に明確になる。特定の区別に従ってモデル要素を定義することで、モデル要素の意味が鮮明になる。個々の要素に対して実績のあるパターンに従うことで、実際に実装できるモデルを作れるようになる。

Eric Evans. エリック・エヴァンスのドメイン駆動設計 (Japanese Edition) (pp.62-63). Kindle 版.

ドメインモデルに関係するコード全部を1つの層に集中させ、ユーザインタフェース、アプリケーション、インフラストラクチャのコードから分離すること。表示や格納、アプリケーションタスク管理などの責務から解放されることで、ドメインオブジェクトはドメインモデルを表現するという責務に専念できる。これによって、モデルは十分豊かで明確になるように進化し、本質的なビジネスの知識をとらえて、それを機能させることができるようになる。

Eric Evans. エリック・エヴァンスのドメイン駆動設計 (Japanese Edition) (p.68). Kindle 版.

第5章ソフトウェアで表現されたモデル

その要素とは、エンティティ、値オブジェクト、サービスである。

Eric Evans. エリック・エヴァンスのドメイン駆動設計 (Japanese Edition) (p.79). Kindle 版.

値オブジェクト(VALUE OBJECTS)

あるモデル要素について、その属性しか関心の対象とならないのであれば、その要素を値オブジェクトとして分類すること。値オブジェクトに、自分が伝える属性の意味を表現させ、関係した機能を与えること。値オブジェクトを不変なものとして扱うこと。同一性を与えず、エンティティを維持するために必要となる複雑な設計を避けること。

値オブジェクトを構成する属性は、概念的な統一体を形成すべきである

Eric Evans. エリック・エヴァンスのドメイン駆動設計 (Japanese Edition) (p.97). Kindle 版.

第7章言語を使用する：応用例

配送仕様は値オブジェクトである。

Eric Evans. エリック・エヴァンスのドメイン駆動設計 (Japanese Edition) (p.168). Kindle 版.

第10章しなやかな設計

副作用のない関数(SIDE-EFFECT-FREE-FUNCTIONS)

プログラムロジックのうち、できる限り多くの部分を関数に置くこと。関数とは、目に見える副作用なしに結果を戻す操作である。コマンド（目に見える状態を変更することになるメソッド）は厳密に分離して、ドメインについての情報を戻さない、非常に単純な操作にすること。ある概念が、値オブジェクトの担う責務に合致する場合には、複雑なロジックをその値オブジェクトに移すことによって、副作用をさらに制御すること。

Eric Evans. エリック・エヴァンスのドメイン駆動設計 (Japanese Edition) (p.256). Kindle 版.

副作用のない関数、中でも不変の値オブジェクトに置かれたものは、操作を安全に組み合わせることができる。関数が意図の明白なインタフェースによって示されていれば、開発者は実装の詳細を理解していなくても、その関数を使うことができる。

Eric Evans. エリック・エヴァンスのドメイン駆動設計 (Japanese Edition) (p.256). Kindle 版.

表明(ASSERTIONS)

操作の事後条件と、クラスおよび集約の不変条件を宣言すること。プログラミング言語で表明を直接コーディングできない場合は、その代わり、自動化されたユニットテストを書くこと。プロジェクトの開発プロセスのスタイルに合う場合には、表明をドキュメンテーションや図の中に記述すること。

Eric Evans. エリック・エヴァンスのドメイン駆動設計 (Japanese Edition) (p.262). Kindle 版.

感想

値オブジェクトに関する記述はいろんな章に分散している…。そもそも読み方が難しい。
「第2部モデル駆動設計の構成要素」の図に、モデル駆動設計の値オブジェクトが含まれていることがわかる
レイヤー化アーキテクチャの部分では、ドメインモデルとドメインオブジェクトを分けて説明している。ドメインモデルの考え方を反映した実装がドメインオブジェクト。
ドメインモデルの構成要素は、エンティティ、値オブジェクト、サービスである
値オブジェクトには「関係した機能を与えること」としている。つまり振る舞い(メソッド)を持たせる、と読むのが自然
「値オブジェクトは概念的な統一体である」の、概念とはドメインモデルのことを指すと文脈から読める
「第10章しなやかな設計」では値オブジェクトが振る舞いを持つ、と示されている
- DTOのような、単なるデータ保持役ではない、と読める
- 図10.4は塗料(値オブジェクト)の例があり、振る舞いを提供している
集約およびクラス(=ドメインオブジェクト)は不変条件(invariant)を宣言すること、と読める

『Domain-Driven Design Reference』Definitions and Pattern Summaries

著 Eric Evans

https://www.domainlanguage.com/wp-content/uploads/2016/05/DDD_Reference_2015-03.pdf

DDD本のサマリとなる本。短くてわかりやすい。しかもダウンロードできる。

Value Objects

Therefore:

When you care only about the attributes and logic of an element of the model, classify it as a value object. Make it express the meaning of the attributes it conveys and give it related functionality. Treat the value object as immutable. Make all operations Side-effect-free Functions that don't depend on any mutable state. Don't give a value object any identity and avoid the design complexities necessary to maintain entities.

モデルの要素の属性とロジックにしか興味がない場合は、値オブジェクトとして分類する。それが伝える属性の意味を表現させ、関連する機能を持たせる。値オブジェクトはイミュータブルとする。すべての操作は、変更可能な状態に依存しないSide-Effect-Free Functionsにする。値オブジェクトにアイデンティティを与えず、エンティティの維持に必要な複雑な設計を回避する。

Side-Effect-Free Functions

Therefore:

Place as much of the logic of the program as possible into functions, operations that return results with no observable side effects. Strictly segregate commands (methods which result in modifications to observable state) into very simple operations that do not return domain information.Further control side effects by moving complex logic into value objects when a concept fitting the responsibility presents itself.All operations of a value object should be side-effect-free functions.

プログラムのロジックをできるだけ関数に置き、観測可能な副作用を伴わない結果を返す操作とする。コマンド（観測可能な状態を変更するメソッド）は、ドメイン情報を返さない非常に単純な操作に厳密に分離する。さらに、複雑なロジックを値オブジェクトに移行することで、副作用を抑制します。値オブジェクトのすべての操作は、副作用のない関数でなければなりません。

『実践ドメイン駆動設計』

著 Vaughn Vernon(@vaughnvernon)

https://www.amazon.co.jp/dp/B00UX9VJGW

数多くEvans本を参照している

6.1 値の特徴

ある概念が値であるかどうかを判断するときには、その概念が以下の特性を持っているかどうかを見極める必要がある。

そのドメイン内の何かを計測したり定量化したり、あるいは説明したりする。

状態を不変に保つことができる。

関連する属性を不可欠な単位として組み合わせることで、概念的な統一体を形成する。

計測値や説明が変わったときには、全体を完全に置き換えられる。

値が等しいかどうかを、他と比較できる。

協力関係にあるその他の概念に、副作用のない振る舞い[Evans]を提供する。

ヴォーン・ヴァーノン. 実践ドメイン駆動設計 (Japanese Edition) (p.211). Kindle 版.

副作用のない振る舞い

オブジェクトの振る舞いは、副作用のない関数[Evans]として設計できる。

ヴォーン・ヴァーノン. 実践ドメイン駆動設計 (Japanese Edition) (p.218). Kindle 版.

感想

値オブジェクトは説明と等価判定と不変(immutable)以外に以下の責務がある
- 概念的な統一体を形成する
- 振る舞いも提供する

『セキュア・バイ・デザイン』

著 Dan Bergh Johnsson(@danbjson), Daniel Deogun(@danieldeogun), Daniel Sawan

https://www.amazon.co.jp/dp/B09F697K2V

3.2 モデルをコード上で表現するための構成要素

ドメイン駆動設計において、モデルをコード上で表現する　構成要素の中で、本書が特に注目しているものは、エンティティ、値オブジェクト(value object)、集約(aggregate)になります(図3.9)。

3.2.2 値オブジェクト(value obect)

不変条件(invariant)の定義とその確認

しかしながら、これは適切な年齢の範囲ではないため、適切な制約もしくは不変条件(invariant)を年齢の値オブジェクトに持たせて、その値オブジェクトが表現することを明確にしなくてはなりません。

図3.15 値オブジェクトは不変条件を維持しなければならない。

この種の不変条件は値オブジェクトの中に定義すべきであり、他のドメイン・オブジェクトやユーティリティ・メソッドなどに定義すべきではありません。

また、ここで言う不変条件の確認は一般的に妥当性確認(validation)と呼ばれる種類の確認ではないことに注意してください。

5.1　ドメイン・プリミティブ(domain primitive)と不変条件(invariant)

5.1.1 ドメインモデルにおける最小の構成要素としてのドメイン・プリミティブ

値オブジェクトはドメインモデルにおいて重要な概念を表すものです。

ドメイン・プリミティブはドメイン駆動設計の値オブジェクトと同じようなものです。

感想

ドメインモデル(ドメインオブジェクト)の構成要素に、値オブジェクトが含まれる、と示されている
また値オブジェクトは不変条件(invariant)を維持しなければならない、とも示されている

『Patterns, Principles, and Practices of Domain-Driven Design』

著 Scott Millett, Nick Tune

Part III: Tactical Paterns: Creating Effective Domain Models

Chapter 14: Introducing the Domain Model Building Blocks

Each building block pattern is designed to have a single responsibility; it could be to represent a concept in the domain like an entity or a value object, or it could be to ensure that the concepts of the domain are kept uncluttered from lifecycle concerns like the factory or repository objects. In a way, you can view the building blocks as a ubiquitous language (UL) for developers to use as a framework for constructing rich and useful domain models.

Millett, Scott; Tune, Nick. Patterns, Principles, and Practices of Domain-Driven Design (p.310). Wiley. Kindle 版.

各ビルディングブロックのパターンは、単一の責任を持つように設計されています。それは、エンティティや値オブジェクトのようなドメインの概念を表すことであったり、ファクトリーやリポジトリオブジェクトのようなライフサイクルの懸念からドメインの概念をすっきりさせることであったりします。ある意味で、ビルディングブロックは、開発者が豊かで有用なドメインモデルを構築するためのフレームワークとして使用するユビキタス言語（UL）と捉えることができます。

感想

値オブジェクトはエンティティと同様にドメインの概念を表す

『Learning Domain-Driven Design』

著 Vladik Khononov(@vladikk)

https://www.amazon.co.jp/dp/B09J2CMJZY

数多くEvans本を参照している

Chapter 6. Tackling Complex Business Logic

Domain Model

The domain model pattern is intended to cope with cases of complex business logic. Here, instead of CRUD interfaces, we deal with complicated state transitions, business rules, and invariants: rules that have to be protected at all times.

Khononov, Vlad. Learning Domain-Driven Design . O'Reilly Media. Kindle 版.

ドメインモデルパターンは、複雑なビジネスロジックのケースに対処するためのものである。ここでは、CRUDインターフェースの代わりに、複雑な状態遷移、ビジネスルール、不変条件、つまり常に保護されなければならないルールを扱います。

Implementation

A domain model is an object model of the domain that incorporates both behavior and data. DDD’s tactical patterns—aggregates, value objects, domain events, and domain services—are the building blocks of such an object model.

Khononov, Vlad. Learning Domain-Driven Design . O'Reilly Media. Kindle 版.

ドメインモデルとは、振る舞いとデータの両方を取り込んだドメインのオブジェクトモデルである。DDDの戦術的パターンである集約、値オブジェクト、ドメインイベント、ドメインサービスは、このようなオブジェクトモデルのビルディングブロックである。

感想

値オブジェクトは振る舞いとデータを含むドメインモデル(ドメインオブジェクト)である、と示されている
また、ドメインモデルには状態遷移・ビジネスルール・不変条件(invariant)への関心も含まれるようだ

『現場で役立つシステム設計の原則〜変更を楽で安全にするオブジェクト指向の実践技法』

著増田亨(@masuda220)

https://www.amazon.co.jp/dp/B073GSDBGT

数多くEvans本を参照している

「送料」クラスのように、業務で使われる用語に合わせて、その用語の関心事に対応するクラスをドメインオブジェクトと呼びます。アプリケーションの対象領域（ドメイン）の関心事を記述したオブジェクトという意味です。

増田亨. 現場で役立つシステム設計の原則〜変更を楽で安全にするオブジェクト指向の実践技法 (Japanese Edition) (Kindle の位置No.597-599). Kindle 版.

・業務の関心事に対応したクラス（ドメインオブジェクト）を作る

増田亨. 現場で役立つシステム設計の原則〜変更を楽で安全にするオブジェクト指向の実践技法 (Japanese Edition) (Kindle の位置No.609-610). Kindle 版.

「値」を扱うための専用のクラスを作る

増田亨. 現場で役立つシステム設計の原則〜変更を楽で安全にするオブジェクト指向の実践技法 (Japanese Edition) (Kindle の位置No.681). Kindle 版.

正しい数量を扱うための独自クラス（Quantityクラス）を定義する

増田亨. 現場で役立つシステム設計の原則〜変更を楽で安全にするオブジェクト指向の実践技法 (Japanese Edition) (Kindle の位置No.650-651). Kindle 版.

このように計算結果も含めて、数量が1以上で100以下であるように制限したQuantityクラスを用意することで、数量計算が安全で確実になります。

増田亨. 現場で役立つシステム設計の原則〜変更を楽で安全にするオブジェクト指向の実践技法 (Japanese Edition) (Kindle の位置No.662-664). Kindle 版.

値の種類ごとに専用の型を用意するとコードが安定し、コードの意図が明確になります。このように、値を扱うための専用クラスを作るやり方を値オブジェクト（ValueObject）と呼びます。業務アプリケーションでよく使う値オブジェクトを表に示します。どの値オブジェクトも、int型／String型／LocalDate型など基本データ型のインスタンス変数を1つか2つ持つだけの小さなクラスです。

増田亨. 現場で役立つシステム設計の原則〜変更を楽で安全にするオブジェクト指向の実践技法 (Japanese Edition) (Kindle の位置No.686-690). Kindle 版.

このように、業務の用語をそのままクラス名やメソッド名として使うと、プログラムが業務の説明書になってきます。業務ルールに変更があったときにも、クラス名と業務の用語が一致していれば、プログラム上で変更が必要な箇所を直観的に特定できます。その業務に関係するデータとロジックを特定のクラスに集めて整理しておけば、変更の影響範囲をそのクラスに閉じ込めやすくなります。それに対して値オブジェクトを使わない場合はどうでしょうか。コードはint型やString型だらけになります。そういうソースコードは、コンピュータに対するデータ操作命令としては有効です。しかし、動かすことはできても、そのコードが業務的に何をやっているのか、プログラムを読んだだけでは理解ができません。こういうコードは業務ルールの追加や変更がやりにくくなります。また、int型やString型が扱える値の範囲は、業務で必要な値の範囲とはかけ離れています。そういう値を扱えてしまうプログラムは、思わぬバグを生みがちです。

増田亨. 現場で役立つシステム設計の原則〜変更を楽で安全にするオブジェクト指向の実践技法 (Japanese Edition) (Kindle の位置No.693-702). Kindle 版.

感想

業務とは対象ドメインのことを意味する(はず)
例示された「送料クラス」はドメインオブジェクトである。送料クラスは値オブジェクトに該当するとは書かれていないが、値オブジェクトとして解釈するのが自然。
「値」を扱うための専用のクラスを値オブジェクトとしている。例として数量クラスが登場する。
説明や等価判定や不変(immutable)以外の目的があることを説明している
- 値の種類ごとに型を作成し、コードが安定(挙動が安定するという意味？)し、コードの意図が明確になる、とのこと
- 『セキュア・バイ・デザイン』のドメイン・プリミティブと同じように、その値が取り扱う値の範囲を保護する目的もあると説明されている(不変条件(invariant)の維持)

『ドメイン駆動設計入門ボトムアップでわかる！ドメイン駆動設計の基本』

著成瀬允宣(@nrslib)

https://www.amazon.co.jp/dp/B082WXZVPC

数多くEvans本を参照している

私はレビュアーとして参加

1．4．1 知識を表現するパターン

値オブジェクト（第2章）はドメイン固有の概念（金銭や製造番号など）を値として表現するパターンです。

成瀬允宣. ドメイン駆動設計入門ボトムアップでわかる！ドメイン駆動設計の基本 (Japanese Edition) (p.39). Kindle 版.

1．4．3 知識を表現する、より発展的なパターン

値オブジェクトやエンティティといったドメインオブジェクトを束ねて複雑なドメインの概念を表現します。

成瀬允宣. ドメイン駆動設計入門ボトムアップでわかる！ドメイン駆動設計の基本 (Japanese Edition) (p.41). Kindle 版.

Chapter2 システム固有の値を表現する「値オブジェクト」

値オブジェクトはドメインオブジェクトの基本です

成瀬允宣. ドメイン駆動設計入門ボトムアップでわかる！ドメイン駆動設計の基本 (Japanese Edition) (p.44). Kindle 版.

2.4 ふるまいをもった値オブジェクト

値オブジェクトで重要なことは独自のふるまいを定義できることです。

成瀬允宣. ドメイン駆動設計入門ボトムアップでわかる！ドメイン駆動設計の基本 (Japanese Edition) (p.71). Kindle 版.

値オブジェクトはデータを保持するコンテナではなく、ふるまいをもつことができるオブジェクトです。

成瀬允宣. ドメイン駆動設計入門ボトムアップでわかる！ドメイン駆動設計の基本 (Japanese Edition) (pp.71-72). Kindle 版.

2．5．1 表現力を増す

値オブジェクトはその定義により自分がどういったものであるかを主張する自己文書化を推し進めます。

成瀬允宣. ドメイン駆動設計入門ボトムアップでわかる！ドメイン駆動設計の基本 (Japanese Edition) (p.79). Kindle 版.

2.5.2 不正な値を存在させない

もはやシステムにとって異常な値はこのチェックにより許容されません。結果としてシステムは、ルールにしたがっていない不正な値の存在に怯える必要がなくなったのです。

成瀬允宣. ドメイン駆動設計入門ボトムアップでわかる！ドメイン駆動設計の基本 (Japanese Edition) (p.81). Kindle 版.

2．5．3 誤った代入を防ぐ

値オブジェクトを作ることで型の恩恵に与ることができれば、予測不能なエラーが潜む箇所を減らすことができます。

成瀬允宣. ドメイン駆動設計入門ボトムアップでわかる！ドメイン駆動設計の基本 (Japanese Edition) (p.85). Kindle 版.

2.5.4 ロジックの散在を防ぐ

ルールをまとめることは変更箇所をまとめることと同義です。ソフトウェアが変更を受けいれることができる柔軟さを確保するためには、このまとめる作業こそが重要なのです。

成瀬允宣. ドメイン駆動設計入門ボトムアップでわかる！ドメイン駆動設計の基本 (Japanese Edition) (p.88). Kindle 版.

2．6 まとめ

値オブジェクトはドメインの知識をコードへ落とし込むドメイン駆動設計における基本のパターンです。ドメインの概念をオブジェクトとして定義しようとするときに、まずは値オブジェクトにあてはめてみることを検討してみてください。

成瀬允宣. ドメイン駆動設計入門ボトムアップでわかる！ドメイン駆動設計の基本 (Japanese Edition) (p.89). Kindle 版.

3.1 エンティティとは

第2章『システム固有の値を表現する「値オブジェクト」』で解説した値オブジェクトもドメインモデルを実装したドメインオブジェクトです。

成瀬允宣. ドメイン駆動設計入門ボトムアップでわかる！ドメイン駆動設計の基本 (Japanese Edition) (p.92). Kindle 版.

感想

この書籍でも値オブジェクトもドメインオブジェクトである、と示されている
また、等価判定以外に目的がある、と示されている
- 振る舞いを持つ
- 自己文書化
- 不変条件の維持
- 凝集度を高める

『良いコード／悪いコードで学ぶ設計入門保守しやすい　成長し続けるコードの書き方』

著仙塲大也(@MinoDriven)

https://www.amazon.co.jp/dp/B09Y1MWK9N

Evans本を参照している

私はレビュアーとして参加

値オブジェクト（ValueObject）とは、値をクラス（型）として表現する設計パターンです。アプリケーションでは金額、日付、注文数、電話番号など、さまざまな値を扱います。こうした値をクラスとして表現することで、各値それぞれのロジックを高凝集にする効果があります。たとえば金額を単なるint型のローカル変数や引数で制御していると、金額計算ロジックがあちこちに書かれて低凝集に陥ります。また、同じint型の「注文数」や「割引ポイント」が、金額用のint型変数に不注意で代入されてしまう可能性もあります。こうした事態を防ぐために、値の概念そのものをクラスとして定義します。

仙塲大也. 良いコード／悪いコードで学ぶ設計入門保守しやすい　成長し続けるコードの書き方 (Japanese Edition) (p.77). Kindle 版.

感想

値オブジェクトがドメインオブジェクトであるか明記されていないが、値オブジェクトに明らかに不変(immutable)と等価判定以外の目的がある、と示されている
- 凝集度を高めること
- 不変条件(invariant)を維持すること
- 値の概念を表現する

『ドメイン駆動’設計モデリング・実装ガイド』

著松岡幸一郎(@little_hand_s)

https://booth.pm/ja/items/1835632

Evans本を参照している

第6章

ドメイン層の実装

ドメインモデルを表現するもの (ドメインオブジェクト)

– エンティティ

– 値オブジェクト

– ドメインイベント

感想

この書籍でも値オブジェクトもドメインオブジェクトである、と示されている

『ドメイン駆動設計サンプルコード&FAQ』

著松岡幸一郎(@little_hand_s)

https://little-hands.booth.pm/items/3363104

Evans本を参照している

用語の定義

表 1 重要な単語の定義

値オブジェクト

ドメインモデルを表現するオブジェクトで、同一判定を保持する値で行うもの。必ず不変になる。

感想

この書籍でも値オブジェクトもドメインオブジェクトである、と示されている

*1:経験年数が長ければよいのかというとそうでもないですが

*2:詳しいことは下のほうに書いてあるし、具体的にはEvans本を読んでください

*3:優劣の区分ではありませんので間違えないように

*4:歳がバレそうですが、僕が生まれる前からあります

*5:人によっては宗教では？と言われます。そういう人はスクラムも宗教という人が多い。まぁ否定はできませんが、それほど大袈裟なことではないと思っています

*6:優秀な方に多いと思います

Re: Re: ドメイン固有型(値オブジェクト含む)を再考する

2022-05-19T16:32:19+09:00

kumagi.hatenablog.com

こちらの記事への反応です。

違う。値オブジェクトとはID以外で等価判定をするオブジェクトの事であって、RubyのHash、Pythonのdict、C++のstd::unordered_setすらも値によって等価判定を行うのでこれらは値オブジェクトであるがドメイン固有型ではない

RubyのHash、Pythonのdict、C++のstd::unordered_setは、アプリケーションのドメインからみるとインフラストラクチャに見えるかもしれません。

しかし、RubyのHash、Pythonのdict、C++のstd::unordered_set であっても、解決する問題領域(ドメイン)があります。なので、そのドメインにとっては、ドメイン固有型(=ドメインオブジェクト)である、と解釈しています。(ドメイン固有型の”固有”が紛らわしかったかもしれませんが…)

型クラスを既存の値型にバリデーションを足すために使う人を見たことが無いけれど（やりたいことは素直なのだから素直にif文やクラスを作るほうがまだわかる）Scalaだとよくある文化なのかしら？

単にバリデーションを追加するためだけにこういうことをするわけではないです。ドメインモデルに実装を対応づけるために定義するという意味でした。

コダックさんのツイートには返信済みでしたが、こういう解釈をしています。

DateやPointが扱う問題ドメインがあるはずなので、矛盾はしないと考えています。
— かとじゅん (@j5ik2o) 2022年5月17日

追記: 5/19 17:13

Evansさん作 Time and Money Code Library(もうメンテされてないけど…)。彼は値オブジェクトのライブラリと言っている。こういう共通性のあるライブラリでも、ドメインはあると思うんだけどね。https://t.co/HSm57PT0LZ
— かとじゅん (@j5ik2o) 2022年5月19日

ドメイン固有型(値オブジェクト含む)を再考する

2022-05-17T13:55:31+09:00

Value Objectが盛り上がっているらしい。

Value Objectについて整理しよう - Software Transactional Memo

Value Objectの説明に異論がないものの、主題はValue Object Obsessionのほうですよね。

こちらも聞いてみた。

fukabori.fm

よい機会なので、よくわかっているつもりの、値オブジェクトというかドメイン固有型について再考してみよう。

それは値か属性か

それはエンティティの全メンバーやデータベースの全列のために「顧客郵便番号」「送付先郵便番号」「事業所郵便番号」「契約日」などのクラス(メンバではなくクラス！)を定義して、immutableな振る舞いを強制する事を以てValue Objectであると言い張り、ドメイン知識の断片をそれぞれのクラスに書き散らして「高凝集になった」「型システムが守ってくれる」と喜ぶ奇行に走る。

これは妥当な指摘だと思います。Twitterの一部で話題になったのですが、この論点は「値(attribute)」と「属性(property)」を混同するなということかと。「その値オブジェクトは値じゃなくて属性のほうじゃないの？」ってやつ。(過去に属性を値オブジェクト化したことがあったかもしれません。やらかしてたらすみません)

Value Object は文字通り "値" なのであって "属性" ではないと思ってるので、引数の取り違えを防ぐみたいな目的に使うのをそう呼ぶのはやめましょう派に属しています。
— やきにく (@a_suenami) 2022年5月11日

たとえば「住所(PostalAddress)」は値オブジェクトになりうるとしても「出荷先住所(ShippingPostalAddress)」はいずれかのオブジェクトの属性であってこれ自体が値オブジェクトではない。

コードにしてみるとものすごい違和感がある…。

// 出荷
public class Shipping {
   // 出荷先住所
   private ShippingPostalAddress postalAddress;
   // あるとしても、こっちでは？ PostalAddress postalAddress;
   // 以下 略
}

仮に、出荷先住所(ShippingPostalAddress)を是とするならば、住所(PostalAddress)からサブタイプを作るのか。それとも継承ではなく委譲を使って特化した型を作るのか。いずれにしても、出荷先住所(ShippingPostalAddress)は、一般的な住所(PostalAddress)より特化した責務を担うのかどうか。なかなか想像しにくい…。通常なら住所(PostalAddress)で十分ではないかと。

しかし、こういう要求が絶対にないとはいいにくい…。特化した要求があるとしても、出荷(Shipping)クラスの中で閉じるのであれば、住所(PostalAddress)で十分かもしれない。他でも再利用されるならば、独自の型が必要になるかもしれない。状況により判断されるのでどちらがいいとも悪いとも言えない。

値か属性かを考えること自体は全く妥当なことだと思う。しかし、値か属性かを明確に判断する基準はつくれるのか…。

属性というのは文脈に紐付く値といえる。そもそも文脈に紐付かない値というのはあり得るのか。『実践ドメイン駆動設計』の「アカウント」モデルの話を思い出そう。「アカウント」モデルのコンテキストは、銀行口座コンテキストなのか、文学コンテキストなのか。「アカウント」モデルは境界づけられたコンテキストの属性的な一面を担っているのではないか。単に値と見ているものでも、暗黙的な文脈があるかもしれない。どのように判断すべきか。

値か属性か、はっきりする場合はよい。しかし、たなかさんがいうように簡単に線引きできる問題ではないかもしれない。グレーゾーンの中にいたら、僕らはどうするべきか。実験の失敗から学ぶしかないのではないか。

英語単語のニュアンスからしても、"what it is"=property、"what it does"=attributeと言いたいのだが、、とはいえ、実運用上、両者の差異は極めてわずかだとも思う。明確な線引きはできないというか、多くの場合両義的だろう、とか。 https://t.co/CiJwrO0Xba
— たなかこういち (@Tanaka9230) 2022年5月11日

振る舞いはPofEAAの値オブジェクトの本質ではないのか

もちろん郵便番号クラスをValue Objectとして実装するのは順当な話であるが、それをValue Object足らしめているのは「比較のために内部の郵便番号の数値を使うオブジェクトとした事」であって「プリミティブ型を包んで振る舞いを足した事」ではない。

こちらについて。不変条件(invariant)を維持するための振る舞いがあったとしても、値オブジェクト由来の概念ではなく、ドメイン固有型(ドメインオブジェクト)が持つ制約でしょうと。つまり、振る舞いの方ではなく、不変と等価判定にこそ存在意義があると読めました。うーん、僕は少し違う解釈をしています。

そして、なんでもかんでも値をラップして、別名割当て問題を回避するために不変にする。さらに等価判定も実装する…。余計な複雑さを取り込んでいるよね…と。まぁこれはわかります。さらに、前述したように属性を誤ってクラス化したりしないように…。

ドメイン固有型はモデリングツールでもある

これは僕の解釈です。値オブジェクトはドメイン固有型の一種です。なので、不変と等価判定だけではなく、なにかしらのドメイン固有の不変条件(invariant)を維持する責任があると考えます(もちろん型として切り出すわけですからその投資に見合うだけの見返りがないといけません)。

PofEAAの値オブジェクトであるMoney型も不変条件(invariant)を維持する操作を備えていると解釈できます。

Moneyの場合、Moneyオブジェクトを数字のように簡単に使えるような、算術演算が必要である。しかし、Moneyの算術演算と数字のMoney演算との間には、重要な相違点がいくつかある。最も明確なのは、異なる貨幣単位の金銭を合算しようとする場合、加算や減算では常に貨幣単位を認識する必要があることである。シンプルでよく使われる対処方法は、異なる貨幣単位の合算をエラーとして処理することである。

つまるところ、値オブジェクトであっても扱う値に健全性がなければ、それは存在価値や利用価値がなくなってしまうので、値オブジェクトである前にドメイン固有型(ドメインオブジェクト)として責任を果たすことは当然だと考えています。詳しくは述べませんが、こう考える理由は『エリックエヴァンスのドメイン駆動設計』(以下DDD) の 第10章しなやかな設計 にあります。

こうした表明が記述するのは、すべて状態であって手続きではないため、容易に分析できる。クラスの不変条件によって、クラスの意味が特徴づけられ、オブジェクトをより予測しやすくすることで、クライアント開発者の仕事が単純化される。事後条件による保証を信用するのであれば、メソッドがどう動くかを気にする必要はない。委譲による影響は、表明の中に組み込まれているはずである。

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

作者:エリック・エヴァンス
翔泳社

Amazon

長くなるので書きませんが理由は他にもあります。「解決する問題にあった設計を作り出すために、中心となる概念を捉えるモデルが必要。そのモデルをツールとしてソフトウェアに組み込む 」みたいな考え方があります。DDDの「第3部より深い洞察へ向かうリファクタリング」あたりに書かれています。『エンタープライズアプリケーションアーキテクチャパターン』(以下 PofEAA), 『UMLモデリングのエッセンス』, 『リファクタリング』ではこのような視点が少なく、DDDとして特徴的な部分だと思います。つまるところ、ドメイン固有型はモデリングツールの側面があるんだと思います。

エンタープライズアプリケーションアーキテクチャパターン

作者:マーチン・ファウラー
翔泳社

Amazon

UML モデリングのエッセンス第3版 (Object Oriented SELECTION)

作者:マーチン・ファウラー
翔泳社

Amazon

リファクタリング既存のコードを安全に改善する（第2版）

作者:ＭａｒｔｉｎＦｏｗｌｅｒ
オーム社

Amazon

なので、値をなんでもかんでもラップしてクラス化*1するという杓子定規ではなく、まずこういった目的に合致するかどうかは、当たり前ですが確認する必要があります。一方で前述したようなデメリットも生じますし、値がプリミティブ型でよい場合もあります。これはトレードオフするしかありません。

ドメイン固有型の手段が「とにかくクラス化する」の一辺倒だから問題が生じやすいという意見もあるので、type aliasやopaque type aliasなど実装手段は最適なものをその状況に合わせて考えたいですね。

Javaの場合、YAGNIに従って後から必要になってからPrimitive Obsessionを避けよう、とすると変更がめちゃめちゃ大変だしIDEで一発変換みたいな事もできないので、最初から全部のクラス作れみたいな方向に行きがちっぽい。KotlinやScalaだとtype aliasが使えるから意思決定の遅延がしやすいのよね
— がくぞ (@gakuzzzz) 2022年5月15日

ドメイン固有型とセキュリティ

「とにかく値オブジェクト化しよう！」は「オブジェクト指向エクササイズの影響ではないか」という話がありました。その説の可能性もありますが、別の説も書いておきます。

「オブジェクト指向エクササイズ」でクセの強いコードを矯正しよう | ALTUS-FIVE

プリミティブ型を避けてドメイン固有型を好む考え方は、『セキュア・バイ・デザイン』の影響もあるのではないかと思います。

セキュア・バイ・デザイン

作者:Dan Bergh Johnsson,Daniel Deogun,Daniel Sawano
マイナビ出版

Amazon

安全なアプリケーションを設計するという観点から、ドメイン固有型＝ドメイン・プリミティブが注目されています。

ドメイン・プリミティブとは、その存在だけで、その値が有効であることを保証する厳格な定義がなされた値オブジェクトのことである。

XSSやインジェクションなど、既知の攻撃を対策すればセキュリティの対策は十分か？答えはノーです。

とあるオンライン書店の話。あるユーザーから$39の本 -1冊の注文を受け付けてしまった。注文金額が$-39となった。明らかに不具合。本来であれば、その書籍を返品しなければなりませんが、そうはならなかった。技術的な問題ではなく、システムがドメインのルールから逸れてしまった問題です。既知の攻撃対策では防げません。

本書では、多くの開発者が汎用的なデータ型を選択するが、セキュリティの観点からそれは大きな間違いであると指摘しています。例えば、電話番号を文字列型として扱うのは便利と考えるかもしれないが、電話番号以外のいかなる種類の値であっても受け入れることができてしまう。これでは不正な入力や操作を防ぎようがない、と。

ドメイン・モデルに含まれる概念はどれも基本データ型やStringのような汎用的な型を使って表現されるべきではありません。ドメイン・モデル内の各概念はドメイン・プリミティブとしてモデリングされるべきであり、そうすることで、そのオブジェクトが様々なところに渡されても、そのオブジェクトの意味が伝わり、不変条件を維持できるようになります。

具体的な例として、UserAccountを表示する入力画面での、XSS対策を考えます。

UserAccountに以下のような対策コードを埋め込むことがありますが、問題があります。XSS以外の問題に対応できない可能性があります。

浅いドメイン理解では、ユーザー名を文字列型として捉えてしまうかもしれません。

public class UserAccount {
   public  UserAccount(long id, String userName) {
      validateForXSS(userName); // XSSを防ぐ
      // ...
   }
}

『セキュア・バイ・デザインでは』、前述のコードではなく以下のよう変更することを推奨しています。

ユーザー名の制約に 4から40文字、半角英数とアンダーバーおよびハイフンのみのルールがあると、深いドメイン理解を得られた場合、以下のような表明*2を追加可能です。ドメイン知識を反映して不変条件を維持すれば、結果的にXSS対策も対策可能になるわけです。

public class UserAccount {
   // ...
   public UserAccount(long id, String userName) {
      this.id = assertLength(userName, 4, 40); // 長さが4以上40以内か
      this.userName = assertPatterns(userName, "^[a-zA-Z0-9_-]+$");  // 文字種が適切か
   }
}

userNameの利用箇所がUserAccountだけならよいですが、他にもあった場合このような表明をあちこちに格納するのは馬鹿らしいので、UserNameとしてのドメイン・プリミティブを新設することになります。こうすれば、UserAccountはUserNameの型を受け取るだけで、正しいユーザー名を受け入れることができます。

public class UserName {
   // ...
   public  UserName(String value) {
      assertLength(value, 4, 40); // 長さが4以上40以内か
      assertPatterns(value, "^[a-zA-Z0-9_-]+$");  // 文字種が適切か
      this.value = value;
   }
}


public class UserAccount {
   // ...
   public UserAccount(long id, UserName userName) { // UserAccountはUserNameを表明すればよいだけになる
      this.id = id;
      this.userName = userName;
   }
}

他の実装例としては、リスト5.1の1〜200個の制約を持つ数量クラス(Quantity)がありますが、内部属性を一つしか持ちません。compound(合成物)ではありません。数量クラスのどんな操作をやっても、0個や201個以上は許容されません。単にintだけを扱ってしまうと、脆弱性の問題に繋がる可能性があるからドメイン固有型を中心に設計しようという考え方です。これはプリミティブ型を辞める理由になると思います。

もちろん、こういった考え方を採用するかは前述したトレードオフを検討すべきです。 どこまでドメインモデルを厳格にするべきか。プレゼンテーション層でバリデーションが終われば、ドメインロジックでわざわざこんなことしなくてもよい？いやいやバリデーション通過後に矛盾が起きる場合はどうするのかなど、考えることがいろいろあります。あと、クラス化が唯一の選択肢なのかも。使える言語が限られますが、型クラスを使えば既存の値型に振る舞いを追加することも可能です。

とはいえ、セキュリティ対策はドメイン固有型を採用する大きなモチベーションになっているのではないでしょうか。私も実際にドメインプリミティブを採用した結果、脆弱性診断でゼロ件を経験したこともあります。「プリミティブ型よりドメイン固有の型を」のエピソードのように、多くの人が探査機を燃やすようなことは避けたいと考えるのではないでしょうか。

ja.wikisource.org

まぁセキュリティ対策のために他のすべてが犠牲になってよいのか。そういう極端なことは現実的ではないので、全体性を考慮に入れるのは当然ですが…。

まとめ

まとめらしい、まとめにならないな…。

まぁドメイン固有型もプリミティブ型も「用法・用量を守ろう」としかいいようがないですね…。個人の開発ならどうでもいいと思いますが、開発者間の合意が必要なケースでは、問題のコンテキストに合致していないのに方法論だけ都合よく抜き取って対策したつもりになるのは避けたいですね。Howの解決策だけでなく、なぜそれをやるのかWhyも整理したほうがよいですね。例えばADRを書くなど。

adr.github.io qiita.com

まぁ、すぐどっちの方法論のよいのか悪いのかと考える癖がありますね。僕もあります。方法論にAとBがあるとして、A＝プラス・B＝マイナスという固定的な見方はしないほうがいい。こういうのを二項対立の思考といいますが、割と無意識にやっています。

ここには思考停止の罠があります。Bのマイナスだって状況が変わればマイナスとも言い切れないわけですから。たとえば、プリミティブ型がプラス、ドメイン固有型がマイナスとした場合、モデリングをそこまで重視しない・セキュリティ対策もそこまで大げさにしなくてもよいシンプルな要件なら成り立ちます。しかし、逆の状況ならプラス・マイナスが逆転するかもしれません。

さらいうと要件が中間レベルにある場合は、AとBのグレーゾーンを考慮しなくてはならなくなります。たとえば、ある部分ではプリミティブ型を重視、違う部分ではドメイン固有型を重視するなど。

二項のうちどちらかに決めつけると不安を払拭できるけど、変化に対する適応力が乏しくなってしまう。二項対立から離れて、グレーゾーンを思考する能力が設計には必要だと思います。

ということで、みなさん頑張っていきましょう。

(余談) そもそもPofEAAとDDDの値オブジェクトが同じかどうか

そもそもPofEAAとDDDの値オブジェクトを同一視できるのかについては、一部で論争がありました。僕もこれについてはよくわかりません。2009年なので13年も前のことです。まだ和訳本がでていない時期…。

Value と Entity - 感想 - Aufheben - GLAD!! の日記

Value ObjectとDTO - yyamanoの日記

DDDのバリューオブジェクトは不変性が本質ではない - かとじゅんの技術日誌

このときの僕の見解

個人的な感想は、やはりDDDとPofEAAで共に出てくる概念に関連性を求めてしまうと混乱する可能性があるなと思いました。似てるところが多いとは言え、完全に同じかというとそれはわからないですね。そこはFowlerとEvansを呼んで概念の関連性を確認しないと、どうにもはっきりしない領域です。

ともあれ、PofEAAのことはさておき、DDDのバリューオブジェクトは、可変も不変もあるので、複製と共有もありと解釈した。大変参考になるエントリでした。気づきを得ることができました。先人に敬意を払いたいですね。

つまりこういうこと

DDDの値オブジェクトとPofEAAの値オブジェクトは似ているようで、解釈が異なる部分がある
DDDの値オブジェクトは不変は必須ではない。もちろん言語や環境に問題がなければ不変であることが望ましい。

1)のような混乱が生じるときは、無理に同一視しなくてもよいと考えています。

(おまけ) Rustではどうするのか

ハイコンテキストな話題なので興味がある人向けです。

JavaのStringは不変です。たとえば String#concat は状態を破壊せずに、追加後の新しいStringインスタンスを返します。仮に、あまりに変更が頻繁なら可変オブジェクトである StringBuilder を使うことになります。共有するなら不変、変更が頻繁なら局所で可変を使うのが基本的な考え方。

Rustの場合も不変がデフォルトですが、String#concatのような新しいインスタンスを返す設計にはほとんどしません。Stringのpush_strは以下のように&mut selfを要求するので、不変参照時では呼びだすことができず、可変参照があるときにしか呼べません。可変を安全に扱えるようになっています。つまりメソッドが可変か不変かを決めるので、わざわざStringBuilderのような型を作る必要がありません。

let orginal = String::from("abc");
println!("orginal = {}", orginal);
// orginal.push_str("def"); コンパイルエラー

let mut modify = orginal.clone();
modify.push_str("def");
println!("modify = {}", modify);

Javaでは可変・不変の型を分ける。Rustではメソッドごとに可変(&mut self)・不変(&self)を分けるだけです。

さらに、Rustであっても、守るべき不変条件(invariant)があれば型として定義することがあるでしょう。たとえば、通貨単位が同一でなければMoney#addできないなど。

github.com

単一の値に制約を課すだけなら、newtypeする以外に、値型のためのtraitの実装を追加する方法もあると思います。

*1:Javaのような言語だとクラスということになりますが、Haskell, Scala, Rustなら型クラスも選択肢になるでしょう

*2:無害なasseretとするか、例外をスローするかは設計判断によるものとします

Rustを使ってスケーラブルなプログラムを書く方法

2021-12-24T10:49:56+09:00

この記事はRust Advent Calendar 2021の12/24日の記事です。

仕事ではScalaを使っていますが、趣味のプログラミングではRustで書いたものが増えました。Rustは楽しいですね。

今回は、Rustでオブジェクト指向プログラミングに関数型デザインを導入することで、スケーラブルなプログラムを書く方法(スケーラブル・プログラミング)について書きます。

「スケーラブル・プログラミング」といえばScalaです。Scalaの「スケーラブル」という言葉には「小さいプログラムも大規模なプログラムも同じ概念で記述できるべきである」という、柔軟性や拡張性を重視した設計の意図が込められています。それを実現するために必要なものは、オブジェクト指向と関数型を組み合わせたマルチパラダイムな設計です。

Scalaはマルチパラダイム言語の先駆者(今も先頭を走り続けています)ですが、他の言語にも広がっています。マルチパラダイム言語の成果は、JavaにScalaが持つ言語機能が取り込まれたり、Rustなどのマルチパラダイム言語の台頭、という形で現れていると思います*1。そういう意味では、スケーラブル・プログラミングは他の言語にも適用可能な時代になっていると考えています。

そして、話を元に戻す…。今回の記事では、その「スケーラブル」という概念を、関数型プログラミングのテクニックを使ってRustに取り入れてみたら、どうなるかを簡単に（！？）説明してみたいと思います。簡単にといいつつ、大作になってしまいました…。*2

想定読者

少なくともRustを「完全に理解した*3」方でないと、おすすめできない記事になっています。

ちなみに、Scalaというキーワードは少しでてきますが、Scala自体の説明はありません。

Scalaを理解しないとRustが使えないということではありません。そのあたりは誤解がないように…。

モナドなどの圏論の話もありませんので、安心してください。

という予防線を張っておき、どんどん関数型な世界に入っていく。

Rustは関数型言語かオブジェクト指向言語か

いきなり蛇足…。「Rustは関数型言語なの？オブジェクト指向言語なの？」という疑問を持つ方は少なくないと思います。

Rustは関数型言語か

Rustは、関数型言語ではなく命令型言語だと言う方が多いです。関数型言語の定義はこんなふうに書いてある。

関数型プログラミング言語（英: functional programming language）とは、関数型プログラミングを推奨しているプログラミング言語である[3]。略して関数型言語（英: functional language）ともいう[4]。

関数型プログラミング - Wikipedia

この定義から考えるとRustは「関数型言語である」とは言えないでしょう。とはいえ、関数型プログラミングに関する機能は取り込まれています。関数型言語かどうかはさておき、関数型プログラミングはできます。

関数型言語の機能：イテレータとクロージャ - The Rust Programming Language 日本語版

Rustはオブジェクト指向言語か

これと似たような話で、Rustはオブジェクト指向言語か？という論争もあります。Rustはクラス・継承・例外・nullがないので、Javaのような既存のオブジェクト指向言語とは一線を画しますが、オブジェクト指向プログラミングはできます(個人の考え)。どちらかというと、C言語でのオブジェクト指向プログラミングに使い方が似ています。

Rustもマルチパラダイム言語

Rustは、手続き型プログラミング、オブジェクト指向プログラミング、関数型プログラミングをサポートする、マルチパラダイム言語です。

Rustはマルチパラダイムプログラミング言語であり、手続き型プログラミング、オブジェクト指向プログラミング、関数型プログラミングなどの実装手法をサポートしている。基本的な制御構文はC言語に似ているが、その多くが式（expression）であるという点においてはML言語に似ている。コンパイル基盤にMIRとLLVMを用いており[10]、実行時速度性能はC言語と同等程度である[11]。強力な型システムとリソース管理の仕組みにより、メモリ安全性が保証されている。

Rust (プログラミング言語) - Wikipedia

「関数型言語か」「オブジェクト指向言語か」という既存のステレオタイプに当てはめようとしても無理があると思います。「あれか・これか」ではなく「あれも・これも」の視点で使い方を考えると生産的ではないでしょうか。

Scala関数型デザイン＆プログラミング

本題に戻ります。

この記事では、以下の書籍(以下 FP in Scala本)中で紹介されるテクニックを、Rustへ輸入する具体的な方法を書いています。

「Rustなんもわからん」もしくは「Rustチョットデキル」の方には考えてみてほしいテーマです。

Scala関数型デザイン&プログラミング ―Scalazコントリビューターによる関数型徹底ガイド (impress top gear)

作者:Paul Chiusano,Rúnar Bjarnason
インプレス

Amazon

当然、コード例はScalaで説明されているわけですが、それをRustに脳内トランスパイルして学び直しました。

この書籍を参考にして作ったもの

この本の中盤の「Part II 関数型デザインとコンビネータライブラリ」という部分では、「プロパティベースのテスト」と「パーサコンビネータ」の解説があります。それに沿って作ったRustの実装は以下です。ほとんど同じ機能かそれ以上の機能を提供しています。

今回「パーサコンビネータ」を通して関数型デザインの考え方を紹介したいので「プロパティベースのテスト」は割愛します。

パーサコンビネータ

パーサーとは構文解析器のことです。

パーサーは自前で実装せずにライブラリを使うことが一般的だと思います。そのパーサライブラリには、パーサージェネレータとパーサコンビネータの大まかに二つの種類があります。

パーサージェネレータ

全く実用性はありませんが、過去にJavaで四則演算だけができる言語を作りましたが、JavaCCというパーサージェネレータを使いました。パーサージェネレータはその名の通り、特殊な記法で記述されたルールに基づき、パーサーを生成してくれるツールです。

数値がBigDecimal型な計算式言語を作ってみた - かとじゅんの技術日誌

パーサーコンビネータ

今回は、パーサーをジェネレートする必要のない、パーサコンビネータを紹介します。FP in Scala本によると以下のように説明されています。

パーサーコンビネータライブラリのパーサーは、どこにでもあるファーストクラスの値にすぎません。解析ロジックを再利用するのはいとも簡単なことであり、プログラミング言語以外に外部ツールの類いはいっさい必要ありません。

今回実装したパーサコンビネータでは、空白やタブや改行の連続を解析して破棄するパーサは以下のように簡単に書けます。elm_of(" \t\r\n")は空白やタブや改行の連続を解析するパーサーを返す関数です。of_many0()はそれが0個以上連続することを意味し、discard()は解析に成功すると解析結果を破棄することを意味します。of_many0, discardはパーサーと組み合わせて利用するので、コンビネータ*4と呼ばれます。

fn space<'a>() -> Parser<'a, char, ()> {
  elm_of(" \t\r\n").of_many0().discard()
}

読み込んだ文字や文字列がパターンに合致するかなどの手続きのHowを記述するのではなく、パーサーコンビネータでは、その構文が何か(What)をそのままコードとして表現するスタイルになります*5。

なぜパーサコンビネータライブラリを自作したのか

Starが多いRust製のパーサーライブラリは以下です。

どれもそれなりに使えます。

nomのインターフェイスは扱いづらい

nomを使ってURIのパーサーを実装しましたが、関数の呼びだしが g→h→f のような解析順であっても、f(h(g()))のような入れ子になります。直感的にコードを記述できないです。

uri-rs/ipv6_address_parsers.rs at main · j5ik2o/uri-rs · GitHub

構文ルールに合わせて、左から順番にコードが読めないのはつらい…。

pub(crate) fn ls32(i: Elms) -> UResult<Elms, String> {
  context(
    "ls32",
    alt((
      map(
        tuple((h16, preceded(complete::char(':'), h16))),
        |(c1, c2)| [c1, c2].join(":"),
      ),
      ipv4_address_parsers::ipv4_address,
    )),
  )(i)
}

pomは書きやすく読み易い

一方でpomは構文ルールをそのままメソッドチェーンで記述できるので、構文ルールどおりに書きやすいし読みやすい*6。pomでは、g() + h() + f() のように直感的に記述できます。

たとえば、CROND文字列の分を解析するパーサーは以下のように定義できます。

これは入力としてu8なのでバイト列を解析するパーサーの例です。pomの方がnomより読みやすいと思います。one_ofは指定した要素のうちいずかにマッチするという意味です。symは単一の要素にマッチするという意味です。

one_of(b"12345")という数値の羅列ではなく、one_of('1', '5')のようにもう少しすっきり書けないのか…というのはありますが、pomより読みいやすいと思います。

fn min_digit<'a>() -> Parser<'a, u8, Expr> {
  (one_of(b"12345") + one_of(b"0123456789")).map(|(e1, e2)| ValueExpr((e1 - 48) * 10 + e2 - 48))
    | (sym(b'0') * one_of(b"0123456789")).map(|e| ValueExpr(e - 48))
    | (one_of(b"0123456789")).map(|e| ValueExpr(e - 48))
}

そして車輪の再発明へ

ツールを作るだけならpomを使えばよかったのですが、以下の理由で自作(車輪の再発明)することにしました。

関数型デザインを学ぶため
pomにない機能を実装するため

作ったものは鬼昆布(oni-comb-rs)

github.com

鬼昆布は非常に濃いダシがとれる昆布です。生産量が少なく、市場に滅多に出回らない非常に珍しい昆布です。

濃いダシが出るように設計しました(謎

鬼昆布(oni-comb-rs)の使い方

例えば、1+2という文字列*7を解析したい場合は、以下のように記述できます。

elm_digitは0から9までの要素にマッチすると成功するパーサーで、elmは引数の要素にマッチすると成功するパーサーです。

// 入力値
let input = "1+2".chars().collect::<Vec<char>>();

// パーサーの構築
let parser: Parser<char, ((char, char), char)> = elm_digit() + elm('+') + elm_digit();

// 解析の実行
let parse_result: ParseResult<char, ((char, char), char)> = parser.parse(&input);

// 解析結果の取得
let result: ((char, char), char) = parse_result.success().unwrap(); // ((1, +), 2)

パーサーどうしを合成することによって、より複雑な構文を解析するパーサーを構築できます。

charのタプルを返されてもあまり実用的でないので、以下のようにAddExprなどの構造体に変換させることが多いです。

let parser: Parser<char, AddExpr> = (elm_digit() - elm('+') + elm_digit()).map(|(a, b)| AddExpr(a, b));

鬼昆布(oni-comb-rs)を使って何を作ったか

このライブラリを使っていろいろつくりましたが、いくつか紹介します。

URIパーサー

わかりやすい例としてはURIパーサです。今どき、URIパーサーなんて作らないとは思いますが…。気に入ったクレートがなかったのでRFCを参考に実装しました。

oni-comb-rs/uri at main · j5ik2o/oni-comb-rs · GitHub

例えば、URI仕様の一部であるIPv6アドレスのls32は以下のように書けます。

fn ls32<'a>() -> Parser<'a, char, LS32> {
  let p1 = (h16() - elm(':') + h16()).map(|(a, b)| LS32::Ls32(a, b));
  let p2 = ip_v4_address().map(|a| LS32::Ipv4Address(a));
  p1.attempt() | p2
}

h16もパーサーです。Aの次にBというパターンの場合はa + bと記述できます(連言といいます)。a - b + cのように-を使うとbの結果だけ捨てられます。mapは解析に成功した結果が関数へ渡され、解析結果を別の型・値に変換できます。p1.attempt() | p2のattempt()はp1が解析に失敗しても解析を中断しないという意味になります。|は選言といって、AまたはBというパターンの場合で使えます。Parser型はParser<'a, 入力要素型, 解析結果型>です。

JSONパーサー

JSONパーサーは以下に90行足らずで実装できます*8。

oni-comb-rs/json_char.rs at main · j5ik2o/oni-comb-rs · GitHub

配列を解析する処理は以下のように簡潔に記述できます。

valueはJSONに含まれる値(文字列, 数値, 二値, nullなど)を解析するパーサーです。lazyはパーサを返す関数を引数に取り遅延評価します。これはパーサーの初期化処理が循環し、スタックがあふれしてしまうことを回避するための工夫です。of_many0_sepメソッドはselfをデリミタありで0回以上の出現を解析するコンビネータです。この例では、value ,の繰り返しが0回以上という意味になります。解析結果はVec型になります。surroundは引数の順序どおりにパーサーを評価しますが、解析に成功すると第一引数と第三引数のパーサーの結果を捨てます。

fn array<'a>() -> Parser<'a, char, Vec<JsonValue>> {
  let elems = lazy(value).of_many0_sep(space() * elm_ref(',') - space());
  surround(elm_ref('[') - space(), elems, space() * elm_ref(']'))
}

Toys言語

そして、@kmizuさんによる、WEB+DB PRESS vol.125の特集記事のToys言語に興味を持ちました。ちょっとしたミニ・プログラミング言語を作ってみようという企画です。

gihyo.jp

具体的な実装コードはこちら。

GitHub - kmizu/toys: A toy programming language to learn how to design and implement programming languages

Rust版の実装

特集記事の実装はJavaで実装されていましたが、Rustで実装しようと考えました。oni-comb-rsを使って。

詳しく説明しませんが、Rust版の実装コードはこちら。

oni-comb-rs/toys at main · j5ik2o/oni-comb-rs · GitHub

パーサー自体の定義は320行ぐらいでした。実用性は全然ないですが、FizzBuzzを書くことができます。パーサーを実装するよりインタプリタの実装のほうが面白かったです。

fn main() {
  let source = r#"
    fn fizz_buzz(i) {
      if ((i % 3 == 0) && (i % 5 == 0)) {
        println("FizzBuzz");
      } else if (i % 3 == 0) {
        println("Fizz");
      } else if (i % 5 == 0) {
        println("Buzz");
      } else {
        println(i);
      }
    }
    fn main() {
      println("----");
      for (i in 1 to 100) {
        fizz_buzz(i);
      }
      println("----");
    }
    "#;
  let input = source.chars().collect::<Vec<_>>();
  let result = program().parse(&input).to_result().unwrap();
  println!("{:?}", result);
  Interpreter::new().call_main(result);
}

他のRust版の実装

他にもnomやcombineを使った実装があります。ご参考までに。

https://github.com/pione30/toysrust
- nomによる実装
https://github.com/yuk1ty/toy-lang
- combineによる実装

どうやって設計したか

やっとここからが本題。

代数的設計

今回の実装は、代数的設計というものを重視しています。

FP in Scala本では、代数は以下のように説明されています。

代数とは、一つ以上のデータ型を操作する関数の集まりと、そうした関数の間の関係を指定する一連の法則のことです。

つまり、代数とは関数とその関数を合成する法則のことです。この考え方をうまく使うと、スケーラブルなプログラミングができます。

わかるようなわからないような…コードをみたほうが早いのですね。実装コードの抜粋を説明します。

要素(文字)を解析するパーサー

最初に設計した関数は要素(文字)を解析するパーサーを返すelm_pred_ref関数です*9。パーサーを生成するファクトリです。このtraitは要素を解析するパーサーを返す関数を実装します。数値文字列や小文字を解析するパーサーを返す関数も提供されます。elm_pred_ref関数はfがtrueを返すとき、解析に成功し入力の文字への参照を返すパーサーを返します。

ちなみに、関数名のrefというサフィックスは解析結果への参照を返すパーサと返すという意味で、refがついてない関数を利用すると実体の値を返すので複製(Clone)が生じます。refの付いた関数を使うことで、できるだけCloneを遅延させたり最適化させたりできます。

element_parsers.rs

pub trait ElementParsers: Parsers {
// ...
  fn elm_pred_ref<'a, I, F>(f: F) -> Self::P<'a, I, &'a I>
    where
      F: Fn(&I) -> bool + 'a,
      I: Element + PartialEq + 'a;
// ...
// Self::Pは`Parsers`トレイトで定義されているパーサー型のエイリアス
}

このメソッドは内部のParsersImplに実装されており、外部には同名のelm_pred_pref関数で公開されます。

lib.rs

pub fn elm_pred_ref<'a, I, F>(f: F) -> Parser<'a, I, &'a I>
  where
    F: Fn(&I) -> bool + 'a,
    I: Element + PartialEq + 'a, {
    ParsersImpl::elm_pred_ref(f)
  }

使い方は以下のようになります。特に複雑さはないと思います。

let text: &str = "x";
let input: Vec<char> = text.chars().collect::<Vec<_>>();

let parser: Parser<char, &char> = elm_pred_ref(|c| *c == 'x');

let result: ParseResult<char, &char> = parser.parse(&input);

assert!(result.is_success());
assert_eq!(result.success().unwrap(), &input[0]);

文字を解析するだけなら関数より文字自体を指定したほうが楽なので、以下のメソッドも定義します。

element_parsers.rs

pub trait ElementParsers: Parsers {
// ...
  fn elm_ref<'a, I>(element: I) -> Self::P<'a, I, &'a I>
    where
      I: Element + PartialEq + 'a, {
      Self::elm_pred_ref(move |actual| *actual == element)
    }
// ...
}

lib.rs

pub fn elm_ref<'a, I>(element: I) -> Parser<'a, I, &'a I>
where
  I: Element + PartialEq + 'a, {
  ParsersImpl::elm_ref(element)
}

// ...
let parser: Parser<char, &char> = elm_ref('x');
// ...

ちなみに文字と仮定して説明しましたが、要素はI型なので文字(char)以外にバイト(u8)でも扱えます。

`or`パーサー

代数的設計の真骨頂は、このあたりから垣間見えます。

parser1またはparser2の選言を行うパーサーを返すor関数は以下のようにしました。

operator_parsers.rs

pub trait OperatorParsers: Parsers {
// ...
  fn or<'a, I, A>(parser1: Self::P<'a, I, A>, parser2: Self::P<'a, I, A>) -> Self::P<'a, I, A>
    where
      A: Debug + 'a;
// ...
}

これをそのまま使うと以下のようになります。

let p3: Parser<char, &char> = or(p1, p2);
let p6: Parser<char, &char> = or(or(p4, p5), p3);
// ...

読み書きしにくい理由は前述したとおりです。これを以下のように変形します。

let p3: Parser<char, &char> = p1.or(p2);
let p6: Parser<char, &char> = p4.or(p5).or(p3);
// ...

絶対こっちのがほうが読みやすいです。

さらに演算子を再定義して読みやすくします*10。

let p3: Parser<char, &char> = p1 | p2;
let p6: Parser<char, &char> = p4 | p5 | p3;
// ...

第一引数をselfに置き換えたトレイトも提供して内部でOperatorParsers#orを呼ぶようにします。

operator_parser.rs

pub trait OperatorParser<'a>: ParserRunner<'a> {
// ...
  fn or(self, other: Self::P<'a, Self::Input, Self::Output>) -> Self::P<'a, Self::Input, Self::Output>
    where
      Self::Output: Debug + 'a;
// ...

}

さらにRustの演算子再定義の仕組みを使ってOperatorParser#orを呼びようにします。

bitor_impl.rs

impl<'a, I, A> BitOr for Parser<'a, I, A>
where
  A: Debug + 'a,
{
  type Output = Self;

  fn bitor(self, rhs: Parser<'a, I, A>) -> Self::Output {
    self.or(rhs)
  }
}

`and_then`パーサー

parser1の次にparser2という解析を行うパーサーも以下のように定義されます。and_then関数はparser1とparser2の解析結果をタプルで返すパーサーが返します。

operator_parsers.rs

pub trait OperatorParsers: Parsers {
// ...
  fn and_then<'a, I, A, B>(parser1: Self::P<'a, I, A>, parser2: Self::P<'a, I, B>) -> Self::P<'a, I, (A, B)>
  where
    A: Clone + Debug + 'a,
    B: Clone + Debug + 'a;
// ...
}

こちらもorのときと同じです。こんなコードを書かされたら混乱するしかありません…。

let p3: Parser<char, (&char, &char)> = and_then(p1, p2);
let p6: Parser<char, ((&char, &char), &char)> = and_then(and_then(p4, p5), p3);
// ...

同様に変形します。

let p3: Parser<char, (&char, &char)> = p1.and_then(p2);
let p6: Parser<char, ((&char, &char), &char)> = p4.and_then(p5).and_then(p3);
// ...

演算子も再定義します。まぁ+がいいのかどうかはさておき。pomは+だったのでそれに倣いました。

let p3: Parser<char, (&char, &char)> = p1 + p2;
let p6: Parser<char, ((&char, &char), &char)> = p4 + p5 + p3;
// ...

operator_parser.rs

pub trait OperatorParser<'a>: ParserRunner<'a> {
// ...
  fn and_then<B>(self, other: Self::P<'a, Self::Input, B>) -> Self::P<'a, Self::Input, (Self::Output, B)>
  where
    Self::Output: Clone + Debug + 'a,
    B: Clone + Debug + 'a;
// ...
}

add_impl.rs

impl<'a, I, A, B> Add<Parser<'a, I, B>> for Parser<'a, I, A>
where
  A: Clone + Debug + 'a,
  B: Clone + Debug + 'a,
{
  type Output = Parser<'a, I, (A, B)>;

  fn add(self, rhs: Parser<'a, I, B>) -> Self::Output {
    self.and_then(rhs)
  }
}

`Parser`型

パーサーを生成する関数も基本的な例を説明しましたが、そもそもParser型とは何かという話をしていませんでした。パーサーのインスタンスを表すParser型は、簡単に言えばクロージャを内包する型です。

parser

type Parse<'a, I, A> = dyn Fn(&ParseState<'a, I>) -> ParseResult<'a, I, A> + 'a;

pub struct Parser<'a, I, A> {
  pub(crate) method: Rc<Parse<'a, I, A>>,
}

Parse型はクロージャ型のエイリアスで、引数に解析中の状態を表すParseState型ととり、戻り値は解析結果を表すParseResult型です。Parser型はそれを内部に保持しますが、Rc型でラップします。こうすることで、Parser 型のインスタンスがCloneされても同一インスタンスを参照できます。

これをどう実行するかというと、以下のような実装になります。parseもしくはrunメソッドを呼びだすと解析処理を行い解析結果を返します。クロージャ型はFn型なので何度でも解析を実行できる必要があります。なので、クロージャ本体の処理でも所有権を一度消費して2回以上実行できない実装はコンパイルエラーになるので注意が必要です。

parser_runner.rs

impl<'a, I, A> ParserRunner<'a> for Parser<'a, I, A> {
  type Input = I;
  type Output = A;
  type P<'m, X, Y>
  where
    X: 'm,
  = Parser<'m, X, Y>;

  fn parse(&self, input: &'a [Self::Input]) -> ParseResult<'a, Self::Input, Self::Output> {
    let parse_state = ParseState::new(input, 0);
    self.run(&parse_state)
  }

  fn run(&self, param: &ParseState<'a, Self::Input>) -> ParseResult<'a, Self::Input, Self::Output> {
    (self.method)(param)
  }
}

`elm_pred_ref`, `or`, `and_then`の実装

elm_pred_ref, or, and_thenの具体的な実装をみていきましょう。

`elm_pred_ref`の実装

elm_pred_refの実装は以下です。

入力値はparse_state.input()で配意として取得できます。このパーサーでは配列の先頭から1要素への参照を取得しfに渡します。trueの場合はその参照を含むParseResultを成功として返し、falseの場合はParseResultを失敗として返します。

element_parsers_impl.rs

impl ElementParsers for ParsersImpl {

  fn elm_pred_ref<'a, I, F>(f: F) -> Self::P<'a, I, &'a I>
  where
    F: Fn(&I) -> bool + 'a,
    I: Element + PartialEq + 'a, {
    Parser::new(move |parse_state| {
      let input = parse_state.input();
      if let Some(actual) = input.get(0) {
        if f(actual) {
          return ParseResult::successful(actual, 1);
        }
      }
      let offset = parse_state.next_offset();
      let msg = format!("offset: {}", offset);
      let ps = parse_state.add_offset(1);
      let pe = ParseError::of_mismatch(input, ps.next_offset(), 1, msg);
      ParseResult::failed_with_uncommitted(pe)
    })
  }

}

elm_pred_refは他の要素を解析するパーサーの基盤的実装になっています。elm_pred_refさえ実装すれば他のバリエーションの実装が導出されるような設計になっています。

  fn elm_digit_ref<'a, I>() -> Self::P<'a, I, &'a I>
  where
    I: Element + PartialEq + 'a, {
    Self::elm_pred_ref(Element::is_ascii_digit)
  }

`or`の実装

orの実装は以下です。

まずparser1を評価します。その結果が失敗ならparser2を評価しその解析結果を返し、そうでないならparser1の解析結果を返します。

operator_parsers_impl

 fn or<'a, I, A>(parser1: Self::P<'a, I, A>, parser2: Self::P<'a, I, A>) -> Self::P<'a, I, A>
  where
    A: 'a, {
    Parser::new(move |parse_state| {
      let result = parser1.run(parse_state);
      if let Some(committed_status) = result.committed_status() {
        if committed_status.is_uncommitted() {
          return parser2.run(parse_state);
        }
      }
      result
    })
  }

※コミットするかしないかは、p1 | p2 | p3のような複数の選択肢あるときのバックトラックと関係がありますが、本題ではないので説明は割愛します。FP in Scala本に簡単な説明があるので読んでみるとよいかもしません。

`and_then`の実装

and_thenは以下のように実装されます。

operator_parsers_impl

  fn and_then<'a, I, A, B>(parser1: Self::P<'a, I, A>, parser2: Self::P<'a, I, B>) -> Self::P<'a, I, (A, B)>
  where
    A: Clone + 'a,
    B: Clone + 'a, {
    Self::flat_map(parser1, move |a| Self::map(parser2.clone(), move |b| (a.clone(), b)))
  }

二つのパーサーの処理結果をタプルで返すパーサーを作って返しているだけですが、Self::flat_map, Self::mapについて詳しく解説します。

`flat_map`, `map`, `successful`, `failed` の実装

`ParsersImpl#flat_map`

flat_mapはパーサーどうしの計算を結合するために使われるコンビネータです*11。そのflat_mapではparser.run(&parse_state)によってパーサーの評価を行います。その結果が成功ならクロージャfに結果を渡し、fが返すパーサーを実行し、その結果が失敗なら何もせずに失敗を返します。いずれの結果であっても、パーサー型が返ります。

このコンビネータは、あるパーサーの解析結果を、別のパーサーの解析へ繋ぐ場合に使えます。flat_mapは代数的設計の中核を担うコンビネータです。 言いたいことの9割はこれです。

parsers_impl.rs

fn flat_map<'a, I, A, B, F>(parser: Self::P<'a, I, A>, f: F) -> Self::P<'a, I, B>
  where
    F: Fn(A) -> Self::P<'a, I, B> + 'a,
    A: 'a,
    B: 'a, {
    Parser::new(move |parse_state| match parser.run(&parse_state) {
      ParseResult::Success { value: a, length: n } => {
        let ps = parse_state.add_offset(n);
        f(a).run(&ps).with_committed_fallback(n != 0).with_add_length(n)
      }
      ParseResult::Failure {
        error,
        committed_status: is_committed,
      } => ParseResult::failed(error, is_committed),
    })
  }

このコンビネータも、parser1.flat_map(|result| ...)のように記述できます。

`ParsersImpl#map`

mapはパーサーが解析した成功の結果を別の値に変換するコンビネータです。mapはflat_mapとsuccessfulを使って導出できます。successfulは指定した値を返すパーサーを返す関数です。

parsers_impl.rs

  fn map<'a, I, A, B, F>(parser: Self::P<'a, I, A>, f: F) -> Self::P<'a, I, B>
  where
    F: Fn(A) -> B + 'a,
    A: 'a,
    B: Clone + 'a, {
    Self::flat_map(parser, move |e| Self::successful(f(e)))
  }
}

このコンビネータも、parser1.map(|result| ...)のように記述できます。

`ParsersImpl#successful`

ParsersImpl#mapで利用した、ParsersImpl#successfulは、指定された値を返すパーサーを生成します。このパーサーはどんな入力であっても必ず成功するパーサーです。

parsers_impl.rs

  fn successful<'a, I, A>(value: A) -> Self::P<'a, I, A>
  where
    A: Clone + 'a, {
    Parser::new(move |_| ParseResult::successful(value.clone(), 0))
  }

`ParsersImpl#failed`

ParsersImpl#successfulより出番は少ないかもしれませんが、ParsersImpl#failedは指定されたエラーを返すパーサーを生成します。このパーサーはどんな入力であっても必ず失敗するパーサーです。

parsers_impl.rs

  fn failed<'a, I, A>(value: ParseError<'a, I>, committed: CommittedStatus) -> Self::P<'a, I, A>
  where
    I: Clone + 'a,
    A: 'a, {
    Parser::new(move |_| ParseResult::failed(value.clone(), committed.clone()))
  }

`SkipParsers#skip_left`, `skip_right`, `surround`

実は、基本的なパーサーの合成は前述のコンビネータがあれば実現できます。

たとえば、p1 + p2のようにand_thenで繋がった二つのパーサーのうち、いずれかのパーサーの解析結果を捨てる実装は以下のようになります。skip_leftは左のパーサーの解析結果を破棄し、skip_rightは右のパーサーの解析結果を破棄します。and_thenはタプルで解析結果を返しますが、skip_left, skip_rightでは単一の解析結果を返します。さらに、p1 + p2 + p3でp2の結果だけを返すパーサーはsurroundです。skip_left, skip_rightの二つのコンビネータを使って簡単に実装できます。

skip_parsers.rs

  fn skip_left<'a, I, A, B>(pa: Self::P<'a, I, A>, pb: Self::P<'a, I, B>) -> Self::P<'a, I, B>
  where
    A: Clone + Debug + 'a,
    B: Clone + Debug + 'a, {
    Self::map(Self::and_then(pa, pb), |(_, b)| b)
  }

  fn skip_right<'a, I, A, B>(pa: Self::P<'a, I, A>, pb: Self::P<'a, I, B>) -> Self::P<'a, I, A>
  where
    A: Clone + Debug + 'a,
    B: Clone + Debug + 'a, {
    Self::map(Self::and_then(pa, pb), |(a, _)| a)
  }

  fn surround<'a, I, A, B, C>(
    left_parser: Self::P<'a, I, A>,
    parser: Self::P<'a, I, B>,
    right_parser: Self::P<'a, I, C>,
  ) -> Self::P<'a, I, B>
  where
    A: Clone + Debug + 'a,
    B: Clone + Debug + 'a,
    C: Clone + Debug + 'a, {
    Self::skip_left(left_parser, Self::skip_right(parser, right_parser))
  }

or, and_then同様にskip_left, skip_righは演算子を再定義しているので、surround(p1, p2, p3)相当のことはp1 * p2 - p3と記述できます。

mul_parser_impl.rs

impl<'a, I, A, B> Mul<Parser<'a, I, B>> for Parser<'a, I, A>
where
  A: Clone + Debug + 'a,
  B: Clone + Debug + 'a,
{
  type Output = Parser<'a, I, B>;

  fn mul(self, rhs: Parser<'a, I, B>) -> Self::Output {
    self.skip_left(rhs)
  }
}

sub_parser_impl.rs

impl<'a, I, A, B> Sub<Parser<'a, I, B>> for Parser<'a, I, A>
where
  A: Clone + Debug + 'a,
  B: Clone + Debug + 'a,
{
  type Output = Self;

  fn sub(self, rhs: Parser<'a, I, B>) -> Self::Output {
    self.skip_right(rhs)
  }
}

URIのパスを解析するパーサー

実装例としてURIのパスを解析するパーサーを紹介します。

URIのパスはほぼBNFに似た形でコードが書けます*12。

//  path          = path-abempty    ; begins with "/" or is empty
//                / path-absolute   ; begins with "/" but not "//"
//                / path-noscheme   ; begins with a non-colon segment
//                / path-rootless   ; begins with a segment
//                / path-empty      ; zero characters
pub fn path<'a>() -> Parser<'a, char, Option<Path>> {
  (path_rootless().attempt() | path_abempty(true).attempt() | path_absolute().attempt() | path_noscheme())
    .opt()
    .name("path")
}

このパーサーを構成するpath_abemptyも内部実装はファクトリやコンビネータを組み合わせます。

//  path-abempty  = *( "/" segment )
pub fn path_abempty<'a>(required: bool) -> Parser<'a, char, Path> {
  let n = if required { 1 } else { 0 };
  ((elm('/') + segment()).collect())
    .map(String::from_iter)
    .repeat(n..)
    .map(|e| Path::of_abempty_from_strings(&e))
    .name("path-abempty")
}

(elm('/') + segment()).collect()は、collect()はマッチすると入力の文字列への参照(&str)をそのまま返します。ゼロコピーの解析処理を記述できます。&strままだと扱いづらいので.map(String::from_iter)でStringに変換します。このパターンは複数回出現する想定なので、続くrepeat(n..)でコレクションに変換します。

まとめ

Parser型の設計は、まさに「小さいプログラムも大規模なプログラムも同じ概念で記述できるべきである」を表現しています。一つのことをうまくやる小さなパーサーどうしをコンビネータを使って合成することで、より複雑な問題を解決するパーサーを簡単に実装できる。これが代数的設計によってスケーラブルなプログラミングを実現する方法です。

最後に、FP in Scala本以外で代数的設計を学べる本を以下に紹介しておきます。

Functional and Reactive Domain Modeling

作者:Ghosh, Debasish
Manning Publications

Amazon

長々とお付き合いいただきありがとうございました。flat_mapは偉大！

*1:というか、オブジェクト指向言語や関数型言語の境界線が溶け込んで曖昧になってきているように思えます

*2:丁寧に書くと大作になる。ボリュームが多いと読者は意図をくみとるのに失敗する確率が高くなる、ので難しい…。

*3:このネットスラングを知らない方はこちらをご覧ください→https://togetter.com/li/1783989

*4:高階関数のことです

*5:さらにパーサーはパーサーを組み合わせることで実装可能なので下位層のWhatは上位層のHowになっていきます。下位層には、手続き型のコードはつきものですが、こういった全体の構造からみると一部になります。

*6:実はScala Parser Combinatorsも同じようなインターフェイスになっています。

*7:空白の読み飛ばしをしないと実用的ではないですがここでは割愛

*8:ちなみにこの程度ならpomでも同様に実装できます

*9:文字をわざわざ要素と抽象的な書き方をしたのは、このパーサーが文字以外も解析できるような設計になっているからです。ある規則に沿ったバイト列上の要素であっても解析できます

*10:演算子の再定義がScalaほど柔軟ではないので限界がありますが…

*11:モナドの説明はしません…

*12:RFCの構文規則は結構あいまいに書かれているし、BNFよりPEGに書き直してから実装したほうがいいかもしれません

Rustで真に安全なプログラムを書く方法

2021-12-08T00:00:00+09:00

この記事はRust Advent Calendar 2021の12/8日の記事です。

Rust前提の記事として書きましたが、他の言語にも適用できる考え方なので、ほかの言語勢の方々もよければお付き合い下さい。

今回のテーマは「Rustで真に安全なプログラムを書く方法」についてです。

「真に安全なプログラム」の定義は以下とします。

挙動が安定し、結果が予測可能となる
正しさの基準に基づき、プログラムの間違いを検知することができる

「真に」とはドメイン知識に基づく正しさという意味です。詳しくは後述します。

それと「そもそもRustで実装されるプログラムは安全じゃないのか」という想定質問については「メモリの操作は安全。だが、それだけでは真に安全なプログラムにはならない」が答えになります。これについて興味がある方、ぜひ最後までお付き合いください。

「真に安全なプログラム」を実現するレシピとしては「関数型プログラミング」「ドメイン・プリミティブ」「契約による設計」あたりを使ってみようと思います。

関数型はプログラミングスタイル

先日、関数型は不変が基本のプログラミングスタイルだという記事を書きました *1。

zenn.dev

プログラムが数学的特性を帯びることで、以下のような設計のよい効果が得られます。最初の項目は「真に安全なプログラム」の条件に含めています*2。

挙動が安定し、結果が予測可能となる
プログラムを改修した際、不具合を起こしにくい
副作用が分離されているため、テストがしやすい
宣言的で意図が理解しやすい

この記事ではRustのコード例も記載していますが、Rustでも関数型プログラミングは可能なので同様の効果が見込めます。

ドメイン・プリミティブ（ドメイン固有型）

ドメイン固有型は以下の記事に詳しくまとめています。

qiita.com

関心の対象にあわせた独自の型は、一般的に「ドメイン固有型」や「ドメイン特化型」と呼ばれることがあります。

「それがそんなに有用なの？」という疑問には、この探査機の教訓が答えてくれます。

1999年9月23日、火星探査機「マーズ・クライメイト・オーピター(MCO)」は火星を周回する軌道への突入に失敗し、燃え尽きました。3億2,730万ドルが失われた原因はソフトウェアのエラーでした。そのエラーは、具体的には「単位の混在」でした。同じ数値の単位を、地上のソフトウェアではポンドとしていたのに対し、宇宙船ではニュートンとしていたのです。その結果地上では、宇宙船のスラスタ推力を実際の約4.45分の1とみなしてしまうことになりました。

プログラマが知るべき97のこと

オライリージャパン

Amazon

単位の扱いを間違えないように、プリミティブ型ではなくドメイン固有型を使えば、探査機は燃え尽きることはなかったのではという話です。ドメイン固有型は、間違いを防止するだけでなく、可読性やテスタビリティが向上するという効能もあります。

なぜセキュア・バイ・デザインなのか

最近発売された『セキュア・バイ・デザイン』という書籍でも、ドメイン固有型が「ドメイン・プリミティブ」として取り上げられています。セキュリティを担保する強力なツールとして紹介されています(この記事でもドメイン固有型ではなく「ドメイン・プリミティブ」として表記を統一します)。和訳本が出てから、読書会が各所で立ち上がっているようで盛況ですね。

ということで、少し本題から逸れますが、『セキュア・バイ・デザイン』の話にお付き合いください。

僕も既にこの本を読む前からドメイン・プリミティブを採用して、脆弱性診断でも脆弱性0件を経験したことがあります。自慢？自慢ですね…。

セキュア・バイ・デザイン

作者:Dan Bergh Johnsson,Daniel Deogun,Daniel Sawano
マイナビ出版

Amazon

さて、なぜ『セキュア・バイ・デザイン』がそこまで注目されるか。「ドメイン駆動設計」がセキュリティ対策にも大きなインパクトを与えるからです。

というのは、XSSやインジェクションなどの既知の攻撃を対策するだけがセキュリティ対策ではないからなんです。たとえば、オンライン書店で、既知の攻撃対策は完ぺきでしたが、-1冊の誤注文を受理し請求処理に失敗し返金処理まで至ったという実際の事故例が書籍中で紹介されています。このような問題は既知の攻撃対策では防げません。問題が対象ドメインのルールに依存するので、ドメインモデルに手を入れないと対策できません。

『セキュア・バイ・デザイン』では、ドメイン知識による正しさから逸れた際に、プログラムを安全に停止させるという考え方があります *3。これは後で説明しますが、「契約による設計」に基づいています。これを実現するには、ドメイン知識を設計に反映する必要があります。そう「ドメイン駆動設計」です。セキュリティの問題を解決したければ(セキュリティだけに注目するのではなく)ドメインにフォーカスしろというわけです*4。つまり「真に安全なプログラム」の「真に」とはドメイン知識に基づく正しさという意味になります。

というわけで、セキュリティ対策を口実にドメイン駆動設計をやれますね！（えっ手段の目的化…

こういう話を聞くと「Rustを使ったら安全になるんじゃないの？」という疑問を持つかもしれませんが、メモリに関する操作は安全になりますが、そもそもビジネスルール上安全かは別問題です。明らかにレイヤーが違います。とはいえ、どちらの考え方も有用です。安全性は多層的に考えるべきなので、Rustのメモリ安全性に加えて『セキュア・バイ・デザイン』を適用すれば、真に安全なプログラムへ近づくのではないかと思います。

攻撃を受けないスタンドアローンなシステム、それこそ探査機のシステムであっても*5、自らのシステムが攻撃者になる可能性もゼロではありません。そんな自己矛盾が発生したときどう対処するのかも、『セキュア・バイ・デザイン』からヒントを得られるでしょう。

論よりコード

前置きが長くなりましたが、「関数型プログラミング」と「契約による設計」の観点を取り入れて、設計を考えてみたいと思います。何か題材が必要だと思うので『セキュア・バイ・デザイン』の例をRustで書いてみようと思います。

題材は子猫名リストオブジェクト

『セキュア・バイ・デザイン』の第4章に登場する、子猫の名前を集合として管理するオブジェクトの例です。本書内のコードはJavaですが、ざっとRustで書き直すと以下のような形になります。実はこれもドメイン・プリミティブです。Vec<String>型をそのまま利用せずに、有用なメソッドを介して利用する想定です。ただこのままだと問題が多そうです…。

pub struct CatNameList {
  cat_names: Vec<String>,
}

impl CatNameList {
  /// コンストラクタ相当
  pub fn new() -> Self {
    Self { cat_names: Vec::new() }
  }

  /// - 事前条件
  ///   - 子猫の名前には「ｓ」が含まれていること
  ///   - まだ登録されていない名前であること
  pub fn queue_cat_name(&mut self, name: &str) {
    self.cat_names.push(name.to_string());
  }
  
  /// - 事前条件
  ///   - 候補となる子猫の名前が登録されていること
  pub fn next_cat_name(&self) -> Option<&String> {
    self.cat_names.get(0)
  }
  
  /// - 事前条件
  ///   - 候補となる子猫の名前が登録されていること
  pub fn dequeue_cat_name(&mut self) {
    self.cat_names.remove(0);
  }

  pub fn size(&self) -> usize {
    self.cat_names.len()
  }
}

現状の何が問題なのか？

守るべき事前条件はコメントに記載しましたが、お気づきのとおり、この実装は契約を守っていません…。

『オブジェクト指向入門第2版原則・コンセプト』の「契約による設計」では、欠陥（バグを含む）と判断する正しさとして、以下のような考え方が示されています。これもすごい鈍器本ですが、興味があればぜひ手にとってみてほしい…。

正しさとは相対的な概念である
ソフトウェア要素そのものが正しいかどうかではなく、対応する仕様と一致するかを論ずるべき(ソフトウェア要素と仕様のペアで考える)
正しさを評価するには、顧客(クライアント)と提供者(サービス)間で取り決める「契約」を定義し、その「契約」に沿っているか判断する
「契約」に沿っているかは「表明」を使った仕様の記述方法を利用するのが一般的

オブジェクト指向入門第2版原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング)

作者:バートランド・メイヤー
翔泳社

Amazon

コード例で示した、守るべき事前条件は「契約」の一種です。

ところで、このコードをみてどんな感想を持ちましたか？「えっ気にしたことがなかった」「バリデーションしてるから大丈夫」「テストしてるから大丈夫」とかでしょうか。本当にそう思いますか？

例えば、プログラマーが正しくないロジックを書いた場合、プログラムは契約を違反したまま実行します。契約は守るべきルールですが、それが守られないまま実行します。つまり期待した挙動にはなりません。意図した振る舞いから逸れることになるので「欠陥」と言えます。バグもこの概念に含まれます。欠陥の詳細については以下の記事を見てもらうとよいと思います。

zenn.dev

エラーはリカバリ可能ですが、欠陥は「通常ありえない状況」で、そのまま続行してもよいことはありませんし、リカバリするものではありません。『達人プログラマー ―熟達に向けたあなたの旅― 第2版』でもトラッシュよりクラッシュすべきと言われています。RustやGoではパニックさせることが多いでしょう。

「できるだけ早期に問題を検出すれば、早めにクラッシュ（停止）に持っていけるというメリットが出てきます。そして多くの場合、プログラムのクラッシュは最も正しい行いとなるのです。クラッシュさせずに放っておくのは、壊れたデータが重要なデータベースに格納されるのを指をくわえて見ていたり、衣類を 20回ほど連続して洗濯機にかけたりするのと同じことです。」

達人プログラマー ―熟達に向けたあなたの旅― 第2版

作者:David Thomas,Andrew Hunt
オーム社

Amazon

あり得ない状況でも無理やり実行するコードを書いたことがありますが、障害の解析に凄く戸惑ってしまって無駄な時間を溶かした経験があります…。

さらに、このような状況を放置するとよくないです。クライアント（呼出し元）がこのような不完全なモジュールを使うと、契約ではなく現状のサービス（呼出し先）の実装に依存します。そして、間違いに気づいて実装を修正しても、手遅れです。クライアント側が間違いに依存しているので壊れてしまう可能性があります。

こういう話をすると、PHPのmt_rand()関数がすぐに修正できなかったことを思い出しますね。

qiita.com

本来であればクライアントも修正すべきですが、修正規模が大きすぎると難しいかもしれません。仕様に照らして明らかに間違っているのにそれを正せない。いつのまにかそれが正しいと言わざるを得ない状況になり、何が正しいか曖昧な状況になりかねません…。

このような事態を避けるには、少なくとも開発者がドメイン知識に関心を持たないと難しいと思います…。

表明(値による表明)を導入する

ということで、事前条件を表明する実装に変更してみましょう。以下のように実装してみました*6。事前条件から逸れたときは正しくない状況なのでpanic!するようにしました。

use once_cell::sync::Lazy;
use regex::Regex;

#[derive(Debug)]
pub struct CatNameList {
  cat_names: Vec<String>,
}

// 正規表現型(Regex)のインスタンス
static REGEX: Lazy<Regex> = Lazy::new(|| Regex::new(r".*s.*").unwrap());

impl CatNameList {
  /// コンストラクタ相当
  pub fn new() -> Self {
    Self { cat_names: Vec::new() }
  }

  /// - 事前条件
  ///   - 子猫の名前には「ｓ」が含まれていること
  ///   - まだ登録されていない名前であること
  pub fn queue_cat_name(&mut self, name: &str) {
    if !REGEX.is_match(name) {
      panic!("Must contain s");
    }
    if self.cat_names.contains(&name.to_string()) {
      panic!("Already queued");
    }
    self.cat_names.push(name.to_string());
  }

  /// - 事前条件
  ///   - 候補となる子猫の名前が登録されていること
  pub fn next_cat_name(&self) -> Option<&String> {
    self.cat_names.get(0)
  }

  /// - 事前条件
  ///   - 候補となる子猫の名前が登録されていること
  pub fn dequeue_cat_name(&mut self) {
    if self.cat_names.is_empty() {
      panic!("Must non empty");
    }
    self.cat_names.remove(0);
  }

  pub fn size(&self) -> usize {
    self.cat_names.len()
  }
}

#[test]
fn example() {
  let mut cat_names = CatNameList::new();
  cat_names.queue_cat_name("cats");
  let cat_name = cat_names.next_cat_name().unwrap();
  println!("{:?}", cat_name);
  cat_names.dequeue_cat_name();
  println!("{:?}", cat_names);
}

事前条件を表明するのは、queue_cat_name と dequeue_cat_name だけになりました。事前条件から逸れる＝欠陥（バグを含む）です。その場合リカバリしても意味がありませんので、panic!でプログラムは早期に中断します。ここでは変数の値が正しいか判断するので「値による表明」と呼ぶことにします。

この二つのメソッドに、意図した値による表明が組み込まれました。next_cat_nameは要素サイズが0個であればNoneを返し、要素が1個以上であればSomeを返すので表明を不要としました。使用例はexampleを参照してください。

本題に関係ないところではありますが、内部データはVecを使っていますが、キューのような振る舞いであればVecDequeを使うほうがよいかもしれません。

可変と不変の使い分け

queue_cat_name, dequeue_cat_nameの二つのメソッドを可変ではなく不変にしたほうがいいのではという指摘もあると思います。

Rust以外の言語では、可変と不変を別々の型で設計することが多いでしょう。例えばJavaのStringとStringBuilderです。Rustでは、型(struct)が不変や可変を決めるのではなく、メソッド(関数)が決めます*7。可変か不変で型(struct)を別々に定義する必要はありません。問題はメソッドを、可変か不変のどちらにするか、という論点になります。

インスタンスを定義するとき、letは不変で、let mutは可変になります。Rustでは、不変インスタンス時に可変操作をしようとすると以下のようにコンパイルエラーになります。queue_cat_nameメソッド、dequeue_cat_nameメソッドは&mut selfが必要なので、このコードではコンパイルできないわけです。不変インスタンス時に誤って可変操作できません。安全な可変操作ができます。

#[test]
fn example() {
  let cat_names = CatNameList::new();
  // 不変インスタンスの場合はコンパイルエラー
  cat_names.queue_cat_name("cats");
  let cat_name = cat_names.next_cat_name().unwrap();
  println!("{:?}", cat_name);
  // 不変インスタンスの場合はコンパイルエラー
  cat_names.dequeue_cat_name();
  println!("{:?}", cat_names);
}

ScalaやKotlinの可変性には豊富なバリエーションがあります。

	Immutable	Mutable
val	😁	😕
var	😀	😱

Rustの場合はシンプルです。Rustの可変性は他の言語と違って安全に扱えるので、😱ではなく😀にしました。

	Immutable(&self)	Mutable(&mut self)
let	😄	※
let mut	-	😀

※に近いことは、T型が&selfであってもRc<RefCell<T>>, Arc<Mutex<T>>などの内部可変性を使うと可能です。

さらに、ここでは詳しく述べませんが、可変参照には以下のような厳しい制約があります。

一つのスコープで一つのインスタンスに対して、可変参照は一つしか取れません
不変参照を借用中は可変参照を借用できません

詳しくは公式ドキュメントを参照してください。

メソッドを不変に変更する

2022/05/15: ここは&mut selfのほうがよいかも。何でもかんでも不変にするとcloneだらけになるので注意してください

可変でも安全に扱えますが、挙動を予測しやすくするにはやはり不変にした方がよいです。不変の例を以下に紹介します。

&mut selfを&selfに変更し、戻り値がSelfに変わります。self.cat_namesの複製に対して可変操作した結果を保持する新しいインスタンスを返します。当然、exampleを変わります。シャドーイングをうまく使ってすっきり書くことができます。

// ...

  pub fn queue_cat_name(&self, name: &str) -> Self {
    if !REGEX.is_match(name) {
      panic!("Must contain s");
    }
    if self.cat_names.contains(&name.to_string()) {
      panic!("Already queued");
    }
    // 複製を作り変更を加え新しいインスタンスを返す
    let mut cloned = self.cat_names.clone();
    cloned.push(name.to_string());
    Self { cat_names: cloned }
  }
  
  pub fn dequeue_cat_name(&self) -> Self {
    if self.cat_names.is_empty() {
      panic!("Must non empty");
    }
    // 複製を作り変更を加え新しいインスタンスを返す
    let mut cloned = self.cat_names.clone();
    cloned.remove(0);
    Self { cat_names: cloned }
  }
}

#[test]
fn example() {
  let cat_names = CatNameList::new();
  let cat_names = cat_names.queue_cat_name("cats");
  let cat_name = cat_names.next_cat_name().unwrap();
  println!("{:?}", cat_name);
  let cat_names = cat_names.dequeue_cat_name();
  println!("{:?}", cat_names);
}

この例では、状態を変えるような操作は常に新しいインスタンスを作ります。すべてのメソッドは引数に対して参照透明性があり、その挙動は予測可能になります。

つまるところ、self.cat_namesの複製をどう考えるかによって設計が変わります。共有される型なら原則不変したほうがよいでしょう。性能上のペナルティが大きいなら&mut selfで局所的な可変を検討するのがよいでしょう。

何を検証すればいいのか

『セキュア・バイ・デザイン』では以下の項目と検証順序が提唱されています。詳しくは書籍を読んでみてください。

オリジン（発生源）
- 正当な送信元から送信されたデータか？
サイズ
- データのサイズは適切か
字句的内容 (lexical content)
- データを構成する文字は正当な文字だけを使っており、正しくエンコードされているか？
構文 (syntax)
- データは正しいフォーマットに沿っているか？
意味 (semantics)
- そのデータは意味的に正しいものか？

今回の場合は、サイズや字句的内容や構文に関する表明を扱っていることがわかります。

型による表明

CatNameList型をさらに改善してみます。

子猫の名前をドメイン・プリミティブ化する

nameを文字列型&strではなく、ドメイン・プリミティブに切り出してみます。

pub struct CatNameList {
  cat_names: Vec<CatName>,
}

impl CatNameList {
// ...
  pub fn queue_cat_name(&mut self, name: CatName) {
    if self.cat_names.contains(&name.to_string()) {
      panic!("Already queued");
    }
    self.cat_names.push(name);
  }
// ...
}

さらに、正規表現を使った表明をCatName側に移動させます。

#[derive(Debug)]
pub struct CatName(String);

static REGEX: Lazy<Regex> = Lazy::new(|| Regex::new(r".*s.*").unwrap());

impl CatName {
  pub fn new(name: &str) -> Self {
    if !REGEX.is_match(name) {
      panic!("Must contain s");
    } 
    Self(name)
  }
}

queue_cat_nameメソッドはCatName型を使います。CatNameのnewメソッドには表明があるのでインスタンス化できれば常に正しいインスタンスであると言えるので、queue_cat_nameメソッドにあったnameに関する表明は不要になります。ドメイン・プリミティブを引数に取ることは値による表明ではなく「型による表明」と呼ぶことにします*8。

常に要素数1個以上となるCatNameList型

子猫の名前のリストが空かどうか、ある値の状態を表明するのは安全なのですが、そもそもそういった「値の表明」を利用せずに安全に操作できないものでしょうか。

CatNameListを、そもそも要素0個でインスタンス化できないように設計を変更します。これも「型による表明」の一種です。どういうことかみていきましょう。

#[derive(Debug)]
pub struct CatNameList {
  head: CatName,
  tail: Option<Rc<CatNameList>>
  size: usize,
}

impl CatNameList {

  pub fn new(head: CatName) -> Self {
    Self {
      head,
      tail: None,
      size: 1,
    }
  }

  fn contains(&self, name: &CatName) -> bool {
    if self.head == *name {
      true
    } else {
      match &self.tail {
        None => false,
        Some(next) => (&*next).contains(name)
      }
    }
  }

  fn combine(&self, other: Self) -> Self {
    let t = match self.tail.as_ref() {
      None => Rc::new(other),
      Some(t) => Rc::new((&*t).combine(other)),
    };
    Self {
      head: self.head.clone(),
      tail: Some(t),
      size: 1 + (&*t).size
    }
  }

  pub fn queue_cat_name(&self, name: CatName) -> Self {
    if self.contains(&name) {
      panic!("Already queued");
    }
    self.combine(CatNameList::new(name))
  }

  pub fn next_cat_name(&self) -> &CatName {
    &self.head
  }

  pub fn dequeue_cat_name(&self) -> Option<&Rc<CatNameList>> {
    self.tail.as_ref()
  }

  pub fn size(&self) -> usize {
    self.size
  }  
}

headに必ず1要素を取るようにし、残りはtailに格納します。tailはtail: Option<Rc<CatNameList>>と少し複雑ですね。Rcはリファレンスカウントを扱う型です。Rcを使うとクローンしても参照のカウント値が加算されるだけでインスタンスのコピーは起きません。今回のケースでは、自己参照型を扱うために使っています。sizeは要素数を表現します。

細かい変更点は以下です。

containsメソッドは、headを比較したのち、tailがあれば委譲するだけです。
queue_cat_nameメソッドは、containsメソッドで含まれていないことを確認したら、combineで要素をリストにして追加します。combineでは現在のtailに引数で与えた新しいリストをcombineしたインスタンスを返します。sizeも同時に計算します。head, tailの構造では末尾に追加する効率が悪いですね…。課題が残りますが、今回の説明は本題がそこじゃないので…。
next_cat_nameメソッドは、もはやself.headの参照を返すだけになりました。常に最初の要素があるのでOptionでラップしなくて済みました
dequeue_cat_nameメソッドも、self.tailの参照を返すだけです。要素数が1個以上か表明する必要もありませんし、後続がある場合でも後続のCatNameListのインスタンスを返すだけなので大きな削除コストはかからないでしょう
sizeメソッドはsizeを返すだけです。この型は不変なので、要素数を一度計算すれば再計算は不要です。

この変更によって、CatNameListが要素数0個で誤って利用されることがなくなりました。間違った操作がそもそもできない設計になりました。これも「型による表明」の効果です。もちろん、「型による表明」は「値による表明」の下支えがないと実現が難しいのですが、重要な部分ではできる限り「型の表明」を適用することを考えたほうがよいでしょう。

まとめ

ところで、ヒューマンエラーの考え方には、フェイルセーフとフールプルーフという考え方があります。フェイルセーフは、システムが故障あるいはエラーを発生させても安全が維持できることです。フールプルーフは人間が誤った行為をしようとしてもそもそも出来ないようにすることです。

「値による表明」は、フェイルセーフの考え方に分類されます。意図した振る舞いから逸れたとき、そのまま続行するとシステムがトラッシュします。それを防ぐために、早期にシステムを中断するからです。一方で「型による表明」は、そもそも危険な操作自体ができない（コンパイルエラーでプログラムとして実行できない）のでフールプルーフに分類されるでしょう。

「値による表明」は実行すれば正しいことが分かる。「型による表明」はコンパイルすれば正しいことが分かる。後者が増えれば、テストを実行するまでもなく、間違いに気づく機会が増えるでしょう、きっと。この考え方が、Rustと合わされば鬼に金棒ですね。

追記：12/8

わかりにくかったかもしれませんが、ErrorとDefect(欠陥)で対応方法が異なります。

ErrorとDefectを勘違いされてると思います。 https://t.co/2OzBfyJNek
— かとじゅん (@j5ik2o) 2021年12月8日

この記事ではErrorの話はしてません。Defect(欠陥)の話です。欠陥なのにResultで返してリカバリしてどうするのでしょう…。もちろん、仕様として、欠陥扱いするのではなく、Errorしてハンドリングしたいというのは設計の段階で精査すべきですね。
— かとじゅん (@j5ik2o) 2021年12月8日

panic!するかResultを返すか公式のドキュメントも参照してみてください。Result型を返すからRustらしいは思考停止だと思います。

*1:オブジェクト指向もプログラミングスタイルです

*2:2も入るかなとは思いますが、改修の方法や手順に依存するかもしれないので今回は条件に含めず

*3:これは代表的なパターン

*4:『セキュア・バイ・デザイン』が既知のセキュリティ対策を軽視しているわけではありません

*5:探査機は地球と交信するので非スタンドアローンのでは…

*6:外部クレートとして遅延初期化のためにonce_cell, 正規表現のためにregexを利用しています

*7:関数に記述されるselfの借用記述で決定します

*8:静的型付き言語前提の解説になっていますが、動的型付き言語でも値の型を判定できるのであれば似たようなことはできるかもしれない…

「DDDで複数集約間の整合性を確保する方法 Rev2」に対する考察

2021-03-22T10:25:20+09:00

どうも、かとじゅんです。

松岡さん(id:little_hands)が以下の記事を更新されたそうです。松岡さん自身が悩まれた中で検討したオプションであって、唯一の正解ではないと踏まえたうえで、率直な感想を述べたいと思います。結論からいうと、論旨は前回の記事と変わりませんが、コード例で具体的な考え方を示している点を工夫しています。

little-hands.hatenablog.com

前回の考察記事も古くなったので、最新の記事に併せて考察をまとめ直したいと思います。

blog.j5ik2o.me

ドメインモデル

ドメインモデル図が追加されていますね。以下の３つの集約があるそうです。「一つの集約にまとめればいいよね」という提案はなしという前提で考えます。

ユーザー
タスク
アクティビティ・レポート

「アクティビティ・レポート」は「タスク」もしくは「ユーザー」に関連を持つようです。

「これらのモデルをどう使いたいのか」が知れるともっと有益な議論ができそうです。ユースケースがないと使えるモデルかどうか判断できないと思います…。

主なユースケースは想定で考えるなら以下とか？ドメインの振る舞いにフォーカスするために、意図的に「確認」もしくは「閲覧」するユースケースは省略しました。「アクティビティ・レポート」はユーザーが作るものではなく、システム内部で作られるものですよね、きっと。

ユーザーがユーザーアカウントを更新する
システムがユーザアカウントのアクティビティ・レポートを追加する
ユーザーがタスクを作成する
システムがタスクのアクティビティ・レポートを追加する

このユースケースではCRUD臭しかしないので、もう少しモデルが成立するルールみたいなものがあれば面白いのですが…。

以下のような集約ルートになるのでしょうか(コードはScalaです。defがfunに変わったぐらいなので読めると思います)。

case class User(id: UserId, name: UserName, ...) {
  // ...
}
case class Task(id: TaskId, name: TaskName, userId: UserId, ...) {
  // ...
}
case class ActivityReport(id: ActivityId, taskId: Option[TaskId], userId: Option[UserId], ...) {
  // ...
}

アクティビティ・レポートに対する違和感

何度かアクティビティ・レポートという名前を声に出してみる。文字で入力してみる。ActivityReportという名前はActivityReport = Activity + Report に分解できそう。Reportは何かしらのレポート形式を採用するのかもしれない。ActivityをReportするのだからActivityReportの前にまずActivityという概念はありそうだが…。それともActivityReportではなくActivityという名前の方が適切？

こういうふうに、ボケとツッコミでいうと、ツッコミをうまく使ってモデリングを深掘りしていきます。モデルの解釈を広げていくときはボケをうまく使う必要がありますが、今回はツッコミを入れてみました。このあたりの話は勉強の哲学にいろいろ書いてあるので参考にしてみてください。

勉強の哲学　来たるべきバカのために　増補版 (文春文庫)

作者:千葉雅也
発売日: 2020/03/10
メディア: Kindle版

Activityならドメインに関連してそうだが、ActivityReportになると急にビューに見えてきます…。頭の中でこれはActivityだと思って話しを進めます(ところで、Activityって何？おそらく過去に起こった出来事？。ドメインイベントに似てますね…)。

それにしても、ActivityReportのtaskId, userId はどちらか一方しか使われないわけで、微妙ですね…。別々の型や集合に見える。TaskActivityやUserActivityのほうがわかりやすくないか。”なぜわかりやすいかどうか”は多分にユーザーの関心や利害に結び付きそう。まずそれを知りたい…。

などと、この時点で「そもそも論」を展開すると、本題に入れないので、このモデルでいいことにして話を進めします(笑)。

実装方法1. ユースケースで複数集約を更新する

「複数集約を1ユースケースで更新して良いのか？」について

ユースケースはある機能を一連のプログラム(式次第のイメージ)として表現するものと理解しています。そのために、要件によっては複数の集約を呼び出すこともあるで、この件は問題がないという認識。というか、僕はこれ自体は否定はしていません。むしろ複雑なユースケースでは複数の型の集約を利用する必要があります。なので、このような実装になるだろうと思います。

ただし、複数集約の更新を同一トランザクションに含めるかについては異論があります。集約の中では強い整合性(RDBのトランザクションなど)を、外では弱い整合性(結果整合性)を使うべきだからです。これは前回のブログ記事に書いた通りです。

メリット・デメリットについて

メリット
- 特に異論はないです。
デメリット
- 「アクティビティ・レポート」を「更新し忘れる」の件
  - 仕様を満たしていないプログラムなのでバグということかと思います。まずはそれをテストや表明で対策できないか。もちろん型で表明できればベストですがやり過ぎると代償もあるわけで。これについては他の実装方法と併せて後述します。
- うっかり「更新し忘れる」以外のデメリットがあります(基本的に前回の記事で書いた通りです)
  - 強い整合性の境界を持つ集約よりも、外側に二重に強い整合性の境界(Transactionalアノテーションで囲っている範囲)を設けているという点です。本来は集約とトランザクションの境界が一致していることが望ましいのですが、以下のようなユースケース毎に強い整合性の境界が設定されています。ユースケースの内側に張り巡らされた、集約の枠を飛び越えた強い整合性を基にロジックが組まれることになります…。集約はそれ単体で整合性が独立するはずですが、この設計では独立していないことになってしまうわけです。このような環境下では、二つの集約の関係は密結合になるリスクもあります。というのがDDDとしての立て付けだと思います。
    - 個人的には、今回のケースではRDB以外はない想定でしょうしTransactionalアノテーションをつけても大きな実害はなさそうです。DDDの集約の考え方に沿うなら結果整合でユースケースを実装するべきですが、もちろんそれ以外の設計の選択はあります*1。つまるところ、どんな選択をするにしても設計(How)のコンテキスト(Why)に納得感があればよいのではないでしょうか。とはいえ、このように集約とは異なるものを「集約」と呼ぶのはいかがなものかと思っています。本来の集約とは違う解釈の「集約」が、割れ窓理論的に捉えられてしまうリスクを懸念します。

「実装方法2. ユースケースで複数集約を更新する」や「実装方法3. ドメインイベントを使用する」について

結論からいうと、さじ加減が難しいところですが、実装方法2も実装方法3も「更新漏れを防ぐ」ために余計な複雑さを導入してしまっていると思います。

実装方法1であっても、以下の方法で正しさを検証すればよいのではないでしょうか

テストで振る舞いが正しいことを検証する
ユースケースのexecuteメソッドの事後条件を表明する

もちろん、この場合でもテストや事後条件自体が間違っていたらどうするのか。テストが正しくても仕様が間違っていたらどうするのか、仕様が正しくても要件が間違っていたら…などと無限に続きます。松岡さん提案の方法でも、TaskCreateParameterを間違って実装して利用すると、結局期待した正しさを得ることができません。

つまるところソフトウェアのおける、正しさとは相対的な概念なのです(出典オブジェクト指向入門第11章契約による設計：信頼性の高いソフトウェアを構築する)。正しさの証明は本来際限がないので、コストとリターンの均衡が取れる適当なところで絶妙に妥協する必要があります。ドメインオブジェクトの型として間違った使い方ができないように考えることは重要なことですが、そのために複雑なコードを組み込んでしまうぐらいなら、立ち止まってテストや表明の範囲に留めます。

オブジェクト指向入門第2版原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング)

作者:バートランド・メイヤー
発売日: 2007/01/10
メディア: 単行本（ソフトカバー）

まぁ確かによいアイデアが思いついて、勢いでリファクタリングすることもありますが、そういうときほど、マクベス症候群(出典レガシーソフトウェア改善ガイド 4.1 規律あるリファクタリング)を発症しないように、一度冷静になった方が良いと思っています。

レガシーソフトウェア改善ガイド (Object Oriented Selection)

作者:クリス・バーチャル
発売日: 2016/11/11
メディア: 単行本（ソフトカバー）

「実装方法3. ドメインイベントを使用する」についても、「更新漏れを防ぐ」ことと天秤にかけてバランスできるでしょうか。僕はそう思えません。Event Sourcingをシステムの耐障害性やスケーラビリティを確保するために導入するなら、ドメインイベントを採用する価値はありそうですが…🤔

じゃぁどうするの

「更新漏れを防ぐ」は上記の方法でバランスをとることにして、ユースケース部分をどう実装したら良いかを考えてみました。大袈裟な仕組みを導入しないでも結果整合にする方法はあるという話です。

ユースケースをRDBのトランザクション境界にしない

ユースケースのexecuteは同一トランザクションに含めずに、以下のようにします。(1),(2)はそれぞれ独立したトランザクションになります。

class CreateTaskUseCase1(
    taskRepository: TaskRepository,
    activityReportRepository: ActivityReportRepository,
) {

  def execute(taskName: String): Unit = {
    val task = Task(taskName)
    taskRepository.store(task) // (1) リポジトリ内でトランザクションが閉じる

    val activityReport = ActivityReport(task)
    activityReportRepository.store(activityReport) // (2) リポジトリ内でトランザクションが閉じる
  }
}

想定問答集は以下です。

Q1, (1)→(2)の順に処理し(2)が失敗したらどうするの？
- 普通に呼び出し元にはエラーを返します。クライアントにもエラーが返ります。
Q2, Taskだけ保存されるとTaskとActivityReportを結合するクエリがおかしくなるのでは？
- Task LEFT JOIN ActivityReportだとおかしくなりますよね。 (1)→(2)の順序ならActivityReport LEFT JOIN Task的なクエリをすれば問題はおきません。
Q3, ユースケースは再実行すると同じタスクIDでINSERTするので失敗するのでは？
- 同じタスクIDなら、INSERT or UPDATEしてください
  - つまりクライアントがユースケースを再実行できるようになっていないといけません。べき等性を担保する必要があります
- 都度ID生成するなら、ゴミTaskが残ることになります
  - 失敗時のゴミレコード vs 同一トランザクションによってロジックが密結合になるリスクのトレードオフになります

結果整合の場合は、すべての更新が完了すれば結果的に正しい状態に収束します。更新中は中間状態が見えるかもしれません。これによってビジネス上大きな問題が起きないように想定しておく必要があります。

この考え方で実際に運用したことあるの？って話ですが、あります。認証/認可に関係する、とあるウェブアプリケーションもこの考え方で設計して数年運用していますが、実用上整合性に関する問題はありません。逆に何でもかんでもトランザクションに含め、ユースケースによってトランザクション境界がちぐはぐに異なるケースではいろいろな問題(一番ヤバいやつはデッドロック…)が起きることを体験しています…。

Taskを更新するユースケースでは

今回の場合は新規追加なのでレースコンディションは起こらないですが、既存の集約を更新するユースケースも考えてみます。

class RenameTaskUseCase1(
    taskRepository: TaskRepository,
    activityReportRepository: ActivityReportRepository,
) {

  def execute(taskId: TaskId, taskName: TaskName): Unit = {
    val task = taskRepository.findById(taskId)  // (F1)
    val renamedTask = task.withTaskName(taskName)
    taskRepository.store(renamedTask)  // (S2)

    val activityReport = ActivityReport(task)
    activityReportRepository.store(activityReport) // (S3)
  }
}

上記のコードでは以下のようにAとBの並行処理がある場合、二つの操作に分離性や独立性がないので、期待した結果にはなりません。

(A-F1) -> (A-S1) -> (B-F1) -> (B-S1) -> (B-S2) -> (A-S2) -> ...

これはロックを導入すれば解決できます。クライアントサーバ型のシステムでは、SELECT ... FROM ... FOR UPDATEで悲観的ロックを利用することがありますが、入力→確認→更新するようなウェブのユースケースではリクエストを跨がってトランザクションを保持し続けるには無理があります。ということで、ウェブでは楽観ロックを使うことが多いです。

class RenameTaskUseCase1(
    taskRepository: TaskRepository,
    activityReportRepository: ActivityReportRepository,
) {

  def execute(taskId: TaskId, taskName: TaskName, taskVersion: TaskVersion): Unit = {
    val task = taskRepository.findById(taskId, taskVersion)  // (F1)
    val renamedTask = task.rename(taskName)
    taskRepository.store(renamedTask)  // (S2)

    val activityReport = ActivityReport(task)
    activityReportRepository.store(activityReport) // (S3)
  }

}

上記の場合は、BのF1はバージョンがすでに更新されているのでTaskが取得できない、もしくはBの(S2)でバージョンが進んでいるため保存に失敗するので、ユースケースの処理はエラーになりデータの不整合を防げます。 (S3)も楽観ロックを提供してもよいですが、常に追記になるなら不要でしょう。

RDB非依存の良さ

前述したように、ユースケースをRDB非依存として設計しておけば、リポジトリのストレージがRDBでもNoSQLでもよくなります。別のマイクロサービス上に存在する集約を呼び出すことも可能です。今どきの分散するシステムにおいては、RDBのトランザクションは一つの選択肢ですが、あらゆる局面で使えるわけではありません。

逆を言えば、RDBしか使わないシステムなら上記は考慮せずに、ユースケースをRDBのトランザクション境界にしても問題ないでしょう。えっ、ほんとに？分散キャッシュを使いたいとかSQSを使いたいとか後から言わないでよ？って意味になります。

実際、後からRedis, Memcachedなど分散キャッシュや、SQSやKafkaなどのメッセージング基盤などを必要することはよくあります。レビューで実際あったのは、RDB前提になってしまったユースケース・ロジックに、以下のようなコードを追加された事例がありました…。まぁキャッシュだけ残ることありますよね…。読者のみなさんはこんな間違いをしないと思いますが。RDBは便利なのですが、このケースでは使い方が間違っていると言わざるを得ません。前述したように結果整合の考え方でユースケースを書き直したほうが無難です。

class RenameTaskUseCase1(
    taskRepository: TaskRepository,
    activityReportRepository: ActivityReportRepository,
) {

  @Transcational
  def execute(taskId: TaskId, taskName: TaskName): Unit = {
    val task = taskRepository.findById(taskId) 
    val renamedTask = task.rename(taskName)
    taskRepository.store(renamedTask)
    // (1), キャッシュとしてRedisに書き込んでいる。
    // (2)でロールバックしてもRedisに永続化されたデータはロールバックできない…
    taskCacheRepository.store(renamedTask)

    val activityReport = ActivityReport(task)
   // (2), DB I/Oエラーが発生しロールバックする
    activityReportRepository.store(activityReport)
  }

}

(蛇足) アクティビティ・レポートはビューモデル？

言いたいことは以上なのですが、論旨が微妙にずれるアクティビティ・レポートについての考察です。蛇足なので時間がある方のみどうぞ。

基本的な考え方は上記と変わりませんが、アクティビティ・レポートのモデルについて考えてみました。

アクティビティ・レポートがどんな属性を持つかわからないのですが、ユースケースが閲覧のみならば、アクティビティ・レポートはビューモデルやリードモデルに見えます。冒頭でもいったように出来事(ドメインイベント)をうまく使えないか。集約内部で発生した出来事(ドメインイベント)をモデリングしてはどうか。振る舞いの結果は新しい状態を表現するインスタンスとドメインイベントを返すようにしました*2。そして、ドメインイベントからアクティビティ・レポートを生成できればよさそうな気がします。まぁ機能的なロジックとしてはほぼ変わらないですが、アクティビティ・レポートにビューの知識があるならこのようにして分離することも可能ではという話です。

case class Task(id: TaskId, name: TaskName, userId: UserId, ...) {
  def rename(value: TaskName): (Task,TaskRenamed) = (copy(name = value), TaskRenamed(...))
  def complete: (Task, TaskCompleted) = (copy(status = Completed), TaskCompleted(...))
}

object Task {
  def apply(id: TaskId, name: TaskName, userId: UserId, ...): (Task, TaskCreated) = {
    (Task(...), TaskCreated(...))
  }
}

sealed trait TaskEvent {
  def id: TaskEventId
  def taskId: TaskId
}
case class TaskCreated(id: TaskEventId, taskId: TaskId, ... ) extends TaskEvent
case class TaskAssigned(id: TaskEventId, taskId: TaskId, assignerId: UserId, assigneeId: UserId, ... ) extends TaskEvent
case class TaskRenamed(id: TaskEventId, taskId: TaskId, taskName: TaskName, ... ) extends TaskEvent
case class TaskCompleted(id: TaskEventId, taskId: TaskId, ..., createdAt: Instant ) extends TaskEvent

class CompletedTaskUseCase1(
    taskRepository: TaskRepository,
    activityReportRepository: ActivityReportRepository,
) {

  def execute(taskId: TaskId, taskName: TaskName, taskVersion: TaskVersion): Unit = {
    val task = taskRepository.findById(taskId, taskVersion)
    val (completedTask, taskCompleted) = task.complete
    taskRepository.store(completedTask)
    taskEventRepository.store(taskCompleted)
  }

}

class ActivityReportDao {
  
   // ActivityReportはリードモデルとして扱う
   def findByTaskId(taskId: TaskId): Seq[TaskActivityReportDto] = {
     // TaskEventが保存されているテーブルからSELECT ... FROM ... JOIN ... するとか、
     // TaskEventを基に別のデータを作成し、それをクエリで返すとか、方法はいくつかあります
   }

}

TaskEvent, UserEventのように型として分けるのか、Eventとしてまとめた型にするのか、そのあたりはよく分かりませんが、この設計だとTaskのステートとTaskのイベント(一つの集約と見なせる)をダブルライトすることになりますね。ここは妥協になってしまうかと。

Event Sourcingでは

ちなみに、Event Sourcingではステートはイベントから導出できるのでイベントしか書き込みません。以下のようなイメージになりますが、このままだといろいろ問題あります。(1)(2)で長大なtaskEventsをリクエスト毎読み込むとパフォーマンスに相応のペナルティがあります。(3)の楽観ロックがないと(4)は無条件に追記されてしまう。これらの問題はAkkaなら簡単に解決できます。

前述したように、システムの耐障害性やスケーラビリティを確保する必要があるならEvent Sourcingは投資対効果がバランスできるかもしれませんが、そういう目的がないなら手段として見合わないと思いますが、考え方は参考になると思います。

class CompletedTaskUseCase1(
    taskRepository: TaskRepository,
    activityReportRepository: ActivityReportRepository,
) {

  def execute(taskId: TaskId, taskName: TaskName, taskVersion: TaskVersion): Unit = {
    val taskEvents  = taskEventRepository.findById(taskId) // (1)
    val task = Task.fromEvents(taskEvents) // (2)
    val taskCompleted = task.complete(taskVersion) // (3) task内部のversionと引数のversionが一致するならcomplete状態に遷移できる
    taskEventRepository.store(taskCompleted) // (4)
  }

}

Akka実践バイブルアクターモデルによる並行・分散システムの実現

作者:レイモンド・ロステンバーグ,ロブ・バッカー,ロブ・ウィリアムズ,前出祐吾,根来和輝,釘屋二郎
発売日: 2017/12/13
メディア: Kindle版

まとめ

ということで、以下まとめです。

今回のモデル構造自体に異論はない
ユースケース内で複数の集約を利用することは問題ない。というか必要
「更新し忘れ」対策はほどほどに
原則はユースケースは弱い整合性の境界、集約は強い整合性の境界。前回書いた記事の主張どおりです
それほどコストをかけずにユースケースを結果整合にする方法はある

ご参考までに。

補足: 3/22

この記事に書いた考え方はマイクロサービスとかやる人向けですと言われることがあります。それはそのとおりですが、そんなにマイクロサービスってハードル高いですか？クラウドとDevOpsで簡単になったはずですよね。身近なものですよ。

ということで、何か参考になる書籍を教えてほしいと言われたので以下の本がオススメです。

「5.2 DDDのAggregateパターンを使ったドメインモデルの設計」で紹介されている「ルール3: 1つのトランザクションで1つのアグリゲートルートを作成または更新する」をぜひ読んでください。この記事と寸分違わない解説がなされています。

マイクロサービスパターン［実践的システムデザインのためのコード解説］ impress top gearシリーズ

作者:Chris Richardson,長尾高弘,樽澤広亨
発売日: 2020/03/23
メディア: Kindle版

*1:わかりきったことでいちいち言及するべきことじゃないと思いますが…

*2:ドメインイベントを戻り値で返すのではなく、Pub/Subするという方法もありますが、意味としては同じなのでここでは戻り値で表現します

「DDDで複数集約間の整合性を確保する方法」に対する考察

2021-03-09T23:13:32+09:00

久しぶりにブログ記事を書きますか。

ということで、松岡さん(id:little_hands)のブログ記事に対する考察記事です。

この記事は古くなったので、ぜひ以下も参照してください。

blog.j5ik2o.me

little-hands.hatenablog.com

題材も松岡さんのブログ記事と同じもので考えます。

「実装方法1. ユースケースで複数集約を更新する」について考察したいと思います。

注意事項）この記事で使うトランザクションという用語は単なる一連の手続きという意味ではなく、ACID特性を持つRDBのトランザクションという意味です。

class CreateTaskUseCase1(
    private val taskRepository: TaskRepository,
    private val taskReportRepository: TaskReportRepository,
) {

  @Transactional
  fun execute(taskName: String) {
    // Taskの作成と保存
    val task = Task(taskName)
    taskRepository.insert(task)

    // TaskReportの作成と保存
    val taskReport = TaskReport(task) // 生成したTask経由でTaskReportを作成している
    taskReportRepository.insert(task)
  }

}

詳しくみていくと、@Transactionalで一つのトランザクションとしていて、TaskとTaskReportは一緒に更新されないといけないようですね。あれ、これってそもそも集約としておかしくないか？と思いました。

集約の外部では結果整合性を用いる

Evansの集約は

複数の集約にまたがるルールはどれも、常に最新の状態にあるということが期待できない。イベント処理やバッチ処理、その他の更新の仕組みを通じて、他の依存関係は一定の時間内に解消できる。[Evans]（128ページ）

であると、実践ドメイン駆動設計の「10.5ルール：境界の外部では結果整合性を用いる」で紹介されています。

ひとつの集約上でコマンドを実行するときに、他の集約のコマンドも実行するようなビジネスルールが求められるのなら、その場合は結果整合性を使うこと。

この説明に従うと、以下のようになるはずです。一つのトランザクションにまとめあげません。集約どうしはそれぞれ結果整合性を使うので、強い整合性がないからです。

class CreateTaskUseCase1(
    private val taskRepository: TaskRepository,
    private val taskReportRepository: TaskReportRepository,
) {

  fun execute(taskName: String) {
    // Taskの作成と保存
    val task = Task(taskName)
    taskRepository.insert(task) // Taskのトランザクション

    // TaskReportの作成と保存
    val taskReport = TaskReport(task)
    taskReportRepository.insert(task) // TaskReportのトランザクション
  }

}

もちろん、TaskReportの更新が失敗したらTaskのロールバックが面倒では？というのあります。とはいえ、集約としての定義はこうなるはずです。

実践ドメイン駆動設計

作者:ヴォーン・ヴァーノン
発売日: 2015/03/19
メディア: Kindle版

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

作者:エリック・エヴァンス
発売日: 2011/04/09
メディア: 大型本

まぁ、たぶん、えーっそれは困るんです。Task集約とTaskReport集約は一緒に更新されないといけないんです、って話ですよね…。その理由がちょっとわからないから考えるのが難しい…。もう少し要件知りたい…。

Lightbend Academyでも集約について以下のように解説されています。

Transactions should not spend multiple aggregate roots.
If you find yourself in a situation where you need to do a transaction that actually crosses aggregate roots, then you've either defined your aggregate roots incorrectly or there's a problem with your transaction and you might have to rethink it a little bit.
トランザクションは、複数の集約ルートを費やすべきではありません。
もし、実際に集約ルートを横断するトランザクションを行う必要がある状況に遭遇した場合は、集約ルートの定義が間違っているか、トランザクションに問題があり、少し考え直す必要があるかもしれません。

とあるので、TaskとTaskReportの場合も、そもそも集約の定義やトランザクションの扱いに問題あるということではないでしょうか。

Will a transaction span multiple entities? If the answer to that question is yes then we can safely say that we have got the wrong aggregate root.
Because again a transaction should not span multiple aggregate root.
トランザクションは複数のエンティティにまたがりますか? この質問の答えがイエスならば、間違った集約ルートを持っていると言っても良いでしょう。
なぜなら、トランザクションは複数の集約ルートにまたがるべきではないからです。

あくまでEvansの集約の定義は、トランザクションなどの強い整合性が有効に働く範囲は集約内部だけという話です。逆に、集約間では結果整合性なので弱い整合性しか使えません。

モデリングに問題はないか

TaskとTaskReportがそれぞれ独立した集約というならば、ここに示されたようにトランザクションは独立していないとおかしいのです。なのに、CreateTaskUseCase1#executeではこれらの集約を一つのトランザクションで更新している。強い整合性で結びつけているのです。

そして”うっかりTaskReport作成を忘れてしまった”がまずいということは、TaskとTaskReportは独立して更新できないことを言っているに等しい。であれば、そもそもTaskとTaskReportは同じ一つの集約ではないのか…と考えます。仮に、そもそもすべてが集約内部に包含されれば、うっかり更新をミスっておかしな状態にならないわけです。

val task = Task(taskName, TaskReport(...))
taskRepository.insert(task)

というわけで、TaskとTaskReportは分かれていないとまずいんです！(再)と聞こえてきそうです(笑) これだと要求を満たせないというのであれば、モデリングに問題あるのでは感。他の実装方法も議論したいところですが、要件をもう少し確認したいなぁという感じ。

追記：少しTwitterで松岡さんと話したので観点を追加(3/10)

集約の境界＝強い整合性の境界

よくあるパターンとしては、Task : TaskReport = 1 : N の関係で、Nが一つのオブジェクトに内包できないぐらい大量にあるという話。この場合は、とれる妥当なオプションとしては以下？

Task : TaskReport = 1 : N の関係

Nを十分に小さくできないか、要求を調整する。たとえば、注文伝票の注文詳細欄は1万行とかある？ないでしょって話
Nを十分に大きく取らざるを得ないなら、別々の集約として独立させて結果整合を許容する

1の場合、Task(TaskReport)だけじゃなくUser(UserReport)という構造もある場合、レポートの知識が分散してしまうとデメリットがあるのではないかという話。レポートがクエリ要件ならTaskReportとUserReportをマージしたリードモデルがあればよい。そうでなくドメインの知識なら型や集合として単一である必要があるのでReport型という独立した集約が必要なので2になる。あと、CQRSの観点でC側のドメインオブジェクトを最適化すれば1を満たせる場合がある。詳しくは → CQRS/ESによって集約の境界定義を見直す - かとじゅんの技術日誌

基本的に1,2で考えれば、集約の構造をみれば整合性の境界が分かる。1対1に紐付く。ユースケースで複数の集約を同一トランザクションに入れてしまうとこれは不鮮明になる。

実践ドメイン駆動設計では、複数の集約を同一のトランザクションで更新するリスクを以下のように述べている。

集約の境界が実際の業務の制約と一致していると仮定して、もしビジネスアナリストが図10‒4のような仕様を出してきたら、それは問題の元だ。考え得るコミット順を考慮していくと、三つのリクエストのうち二つが失敗するいう場合もあることがわかる。この指示が、あなたの設計にどんな影響をおよぼすのだろう?この問いに答えようとすると、ドメインについてのより深い理解が得られる。複数の集約のインスタンスの整合性を保ち続けなければいけないというのは、自分たちが不変条件を見落としているということを意味する。最終的には、その複数の集約をひとつの新たな概念にまとめて名前をつけて、この新たに発見した業務ルールに対応することになるだろう（そしてもちろん、今までの集約群を、この新しい概念に取り込むことになる）。

このようなトランザクションの競合問題を除けば、ほとんどの場合は、複数集約を同一トランザクションにまとめても問題ないだろう。普通に機能するし便利だと思われる…。つまるところ、集約が強い整合性の境界を作るのに対して、ユースケースクラス（アプリケーションサービス）では弱い整合性の境界を作っていると考えてもよい。整合性の境界が入れ子だとしても強い一貫性を発揮する境界は集約であることは変わりない。もちろん、個別ケースにおいてはリスクを取って同一トランザクションに含めることもあるが、原則論としてはこういう考え方になるのは妥当だと思う。

ユースケースクラス（アプリケースサービス）で同一トランザクションにしないで複数の集約を更新する際、ダブルコミットの問題が生じるので、そのリカバリーが厄介になる。以下のように集約Bの更新が失敗した場合、集約Aはすでにコミットされているので、集約Bはリトライしなければならない。もしくは集約Bの更新が失敗しても、クライアントからユースケースAがべき等にリトライできるようにする必要がある。そもそも集約は独立した存在なので、集約Bの更新が失敗しても集約Aへの影響は大きくないはず。クエリサイドで集約Aと集約Bを合成した結果を取得する際は、集約Bだけ古いデータを見ることになるので、こういった制約を想定しておく必要がある。

ユースケースA() {
  集約A更新
  集約B更新
}

集約単位のトランザクションはモジュラリティ確保のために

まぁ、こういう想定をすると益々同一トランザクションに入れたくなるが…僕は入れません。

集約Aと集約Bの更新を同一トランザクションにした場合、ユースケースAを後から分離することが難しくなります。スケーラビリティのために、集約Aと集約Bを別々のサーバで強い整合性を持って実行するということは無理に等しいです（そもそも分けて実行する要求がないと言い切れるなら無視していいことですが…）。両者の更新が常にセットで行われることを期待したロジックができあがり、そのロジックには依存関係が生じます。あとからトランザクションを分けようとすると、大部分の他のロジックが動作しなくなるということはざらにあります。もちろんコードの規模や複雑度にもよりますが…。

// 同一トランザクション前提のロジックを、以下のように分割することはかなり難しい…。
サーバAのユースケースA() {
  集約A更新
}

サーバBのユースケースB() {
  // 集約Aが正しく更新されていることが前提だったが、まだ更新されていないかもしれない…。
  集約B更新 
}

あと、集約Aと集約BのストレージがRDBなら同一にできますが、それぞれ別々のDBであったり、NoSQLであったりする場合はそもそも無理ですね。つまり、@Transactionalなどの手法で一つのトランザクションすることには、同一DBインスタンスを利用するという暗黙的なコンテキストがある。DBを分割したり異種のDB I/Oというコンテキストは含まれない。やはりモジュール性に関する論点かもしれない。

DBを例にしたが、マイクロサービスアーキテクチャの場合はどうだろう。こちらもユースケースで同一トランザクションにすることなどはそもそも無理だ。

ユースケースA() {
  マイクロサービスAの集約A更新
  自マイクロサービスの集約B更新 
}

この場合でも、前節で述べたようにRDBのトランザクションには頼れないので、別のリカバリ方法が必要になります。ここでは詳しく述べませんが、Sagaというテクニックがあります。Sagaは、ACIDの分離性がないことによって引き起こされる並行性の問題を防止・軽減する設計テクニックです。興味がある人は以下の書籍の4章を読むとよいです。こちらの文脈を辿っていくとマイクロサービスなどの分散システムではACIDトランザクションではなく分散トランザクションが必要であることに気づくでしょう。逆にいえば、マイクロサービスではない環境下では、暗黙の大前提としてRDBだからDBのトランザクションを何の疑問もなく使えてしまうというのはあるのではないでしょうか。

マイクロサービスパターン［実践的システムデザインのためのコード解説］ impress top gearシリーズ

作者:Chris Richardson,長尾高弘,樽澤広亨
発売日: 2020/03/23
メディア: Kindle版

長々と書きましたが、トランザクションを同じにするということはモジュールとしても強い依存関係をつくりあげてしまうということではないかと思います。モジュラリティとか疎結合のために集約単位にトランザクションを分けているといってもいいでしょう。

追記: 2021/3/15

CQRSはなぜEvent Sourcingになってしまうのか

2020-09-18T17:26:12+09:00

CQRSはなぜEvent Sourcingになってしまうのか、まとめてみたいと思います。

なぜまとめるか、それはCQRSにとってEvent Sourcingはオプションだと誤解されている方が多いからです。この記事を書いてる本人も最初はそう思っていましたが、実際に開発・運用を経験してみるとCQRSにとってEvent Sourcingはほぼ必須で、認識を改めるべきだと気づきました。なので、原義に基づいたうえで、Event SourcingではないCQRSがなぜよくない設計になるのか解説します。

その前に松岡さんの記事について。

CQRSの領域ではモデルを完全に分ける

松岡さんの記事には”CQRSはモデルを完全に分ける必要はない”と書かれていますが、知識がないと誤解しがちですが文字のまま意味を取るといけません。こちらの言及は、システムのうち、モデルをC/Qに分割するCQRS領域とモデルを分割しない非CQRS領域に分けることができて、CQRSを部分導入できますよいう意味だと思います(下図参照)。モデルを分けなくていいのはあくまで非CQRS領域です。間違っても「CQRSはモデルを分割しなくてもいいんだ！」という解釈をしてはいけません。その解釈はもはやCQRSではありません。

部分的導入について
重要なことですが、CQRSは部分的な導入が可能です。つまり、「参照用モデルと更新用モデルを完全に分ける必要はない」ということです。どちらかというと、「必要なところだけ参照に特化したモデルを導入する」といった使い方が適切でしょう。
CQRS実践入門 [ドメイン駆動設計] - little hands' lab

CQRSはモデルだけでなくモジュールも分割する

さらにモデルを分けるだけではなく、そのモデルを内包するトップレベルのモジュール同士を分離というか、隔離しなければなりません。という話はこちらの記事を参照してください。

blog.j5ik2o.me

シンプルなCQRSの概念図は以下です。上述したようにC/Qは隔離されています。データベースのところはRDB前提で書いていますが、実際の運用ではこうしません。想像しやすいように書いてるだけで、厳密には書いてないと思ってください。

Event SourcingではないCQRSを考える

この記事では、リポジトリからリード専用DAOまでの設計を考えていきましょう。最初はEvent Sourcingを考えずに素直に状態に基づくCRUD脳で考えていきます。

具体的なコードのイメージは以下の記事を読むといいです。

blog.j5ik2o.me

対象ドメインはショッピングカート前提で考えます。

コマンドプロセッサ実装

コマンドプロセッサの実装例です。コマンド側のユースケースクラスだと思ってください。カートオブジェクトとリポジトリの操作をCRUDで考えると以下のように実装になるでしょう。

class AddCartItemCommandProcessor(cartRepository: CartRepository) {

  def execute(cartId: CartId, itemId: ItemId, num: ItemNum): Unit = {
    // 最新の集約(グローバルなエンティティ)をストレージから取得する
    val cart = cartRepository.findById(cartId)
    // ロジック実行: 予算超過ならカートオブジェクトが商品の追加を拒否する！
    val newCart = cart.addItem(itemId, num)
    // 更新された最新状態をストレージに保存する
    cartRepository.store(newCart)
  }

}

まずC側のテーブル(A)とQ側のテーブル(B)は形式が異なるのですが、まずリポジトリによってカートオブジェクトは以下のテーブルに永続化されます。 (カート内のアイテムは別テーブルにマッピングされますが、リポジトリでfindAllByItemIdのような逆引き検索がなければ、子テーブルは不要かもしれませんが、一旦わかりやすさを優先して子テーブルを設けています)

C側のテーブル(A)
- カートテーブル
  - カートID(PK)
  - 顧客アカウントID
  - 上限予算金額
  - 作成日時
- カートアイテムテーブル
  - カートアイテムID(PK)
  - カートID(FK)
  - 商品ID
  - 数量
  - 作成日時

このように永続化されますが、ビジネスロジックで計算する値もあります。カートの合計金額です。あと、商品の単価は外部のオブジェクトから提供されるので、カートオブジェクト内部で保持してません。

case class Cart(id: CartId, userAccountId, upperLimitPrice: Price, items: CartItems, createAt: Instant) {
  // 合計金額計算
  def totalPrice(priceResolver: ItemId => Price): Price = {
    items.fold(Price.zero){ (t, item) => t + item.price(priceResolver) }
  }
}

case class CartItem(id: CartItemId, itemId: ItemId, quantity: Quantity, createAt: Instant)  {
  // 価格計算メソッド
  def price(priceResolver: ItemId => Price): Price = priceResolver(itemId) * quantity
}

クエリプロセッサの実装例

クエリ側のユースケースクラス相当の実装です。クエリ側のリード専用DAOとリードモデルであるDTOは以下のようなイメージになります。

class GetCartQueryProcessor(cartDao: CartDao) {

  def execute(cartId: Long): Vector[CartDto] = {
     cartDao.findByCartId(cartId)
  }

}

case class CartDto (
  id: Long,
  userAccountId: Long,
  userAccountName: String,
  upperLimitPrice: String,
  totalPrice: String
  items: Seq[CartItemDto]
)

case class CartItemDto(
  id: Long,
  itemId: Long,
  itemName: String,
  unitPrice: String
  quantity: Long,
  price: String)

対応するテーブルはDTOと同形で、C側と比べて非正規型になっています。C型と似てるようで似てない。別物です。あとで説明しますが、(★)のところが厄介ですね。

Q側のテーブル(B)
- カートテーブル
  - カートID(PK)
  - 顧客アカウントID
  - 顧客アカウント名(●)
  - 上限予算金額
  - 合計金額(★)
- カートアイテムテーブル
  - カートアイテムID(PK)
  - 商品ID
  - 商品名(●)
  - 数量
  - 単価(★)
  - 価格(★)

補足:

(●)も面倒ですが、これは他の集約(エンティティ)のデータとして永続化されていて、SQLで解決できる可能性があります。

めちゃくちゃ単純ですが、これでC/Qが独立しています。が、C/Qを連携させなければ更新されたデータを読み込むことができません。上図の(C)の部分です。

コマンド側からクエリ側に変更をどう通知するか

はい。やっと本題です。コマンド側からクエリ側に変更をどう通知するか、(C)部分の実装について以下に挙げてみます。

テーブル(A)の更新トリガ時の変更を、SQLを使ってテーブル(B)を書き込む
プログラムで、テーブル(A)を読み込み、その結果をテーブル(B)に書き込む

テーブル(A)の更新トリガ時の変更を、SQLを使ってテーブル(B)を書き込む

トリガー例はあえて書きませんが、更新データを受信してテーブル(B)のレコードをまるっと全カラム書くとよいですね。欲を言えば、更新されたレコードだけを検知したいですが、全カラム更新するしかないと思います。まぁリポジトリで集約(エンティティ)を保存する時点で全カラム更新なら、ここで差分更新を頑張っても釣り合わないですね。と、C側で静的に保持されているデータをQ側に書くだけならトリガーでよさそうです。

問題は(★)の部分。(★)はC側のデータベース上にはありません。ドメインオブジェクトの振る舞いによって計算される値だからです。 まさかドメインロジックと同じ仕様のSQLを書くとかないですよね…。まぁ振る舞いのない貧血症オブジェクトしかないなら、特に問題はないでしょうね(皮肉) あ、例えトランザクションスクリプトであっても、ロジッククラスの助けなしに計算できない値があるとしたら？同じことですよね？

苦肉の策としては計算した結果もC側のテーブルに書き込むという方法です。カートオブジェクトだと、priceResolver引数が外部のオブジェクトなので、まずこれが永続化時にないとこういったことはできません。リポジトリのI/Fを def store(cart: Cart, priceResolver: ItemId => Price): Unitするなど設計に歪みがでることがあります。つまり、リポジトリ内部でビジネスロジックを起動するということです。リポジトリの責務違反…

そもそも、トリガーという時点でイベントに頼ってるような印象ですが、こういう計算で導出される値の扱いは難しいです。

プログラムで、テーブル(A)を読み込み、その結果をテーブル(B)に書き込む

(★)の問題があるから、一度ドメインオブジェクトに計算させてから、テーブル(B)に書けばよいことになります。これならQ側にもれなくデータを転送できそうです。が、変更のトリガーってどう検知しましょうか？まさか、C側のDBに変更されているかどうかわからないけど、ポーリングします？対象の集約はどうしますか？集約が大量にもあっても、それら全部ポーリングします？全然機能するイメージがないですね…。やっぱり最新状態を手に入れるにしても、更新イベントが必要なんです。

補足:

Q側のテーブルをC側のVIEWにすればよいのでは？というアイデアもあると思いますが、(★)の問題はSQLで解決できません。結局ドメインオブジェクトに頼ることになります。

結局 Event Sourcingにたどり着く

上述した2パターンのよいところを組み合わせるとよさそうです。C側のテーブル(A)以外に更新イベントを通知するキューを用意します。以下のようになります。

リポジトリ側でC側のテーブル(A)を更新する以外に、更新イベントを通知するためにキューにもイベントを書き込みます。そのうえで、リードモデル更新プロセスがそのイベントを受け取り、テーブル(A)から集約(エンティティ)を再現し、Q側のテーブル(B)に書き込めばよいです。まぁ、いちいちC側のテーブル(A) を読まずに、変更内容を更新イベントに載せたらどうかという発想もありますね。

一見、これで問題がないようにみえますが、C側のリポジトリは二つのストレージに書き込みを行っています。テーブル(A)はRDB、更新イベントを伝えるキューはRDBは不向きでしょう。AWSであればSQSのようなものを想像するでしょう。となると、同一トランザクションにはなりません。はい。高いコストを払う可能性がある、ダブルコミット問題が生じます。以下の記事でもダブルコミットは避けましょうという話をしました。

blog.j5ik2o.me

ダブルコミットを避けるためにイベントを真のデータソースにします。C側のドメイン状態はイベントから作るようにします。そして、C側のDBはもはやRDBである必要はありません。上記記事にも書きましたが、集約で発生するイベントを追記したり、集約IDごとのイベント列を読み込めれば十分だからです。実際はNoSQL(KVS)を使うことが多いです。AWSのDynamoDBであればDynamoDB Streamsからスケーラブルにイベントを読み込めます。これがEvent Sourcingですね。結局ここにたどり着きます。

CQRSシステムのほとんどがEvent Sourcingを採用しているそうです(Lightbend社調べ)。その理由を分かっていただけたのではないでしょうか。

CQRSはモデルだけでなくモジュールも分割する

2020-09-18T08:49:14+09:00

掲題についての議論です。

僕の結論はこちら。"モジュール分割せずにモデルを分割するだけ"はCQRSと呼んでいけないのでは？まず原義からちゃんと把握しようというお話。

CQRSするにはC/Qは独立しないとダメなので、それをどう連携させるかすごい難しい課題。ESなしでは独立させて統合するのはほぼ難しいと思います https://t.co/Ta0CYujHJx
— かとじゅん (@j5ik2o) 2020年9月17日

sipadan2003.blogspot.com

Gregさんの原義によると

Origins

起源

Command and Query Responsibility Segregation uses the same definition of Commands and Queries that Meyer used and maintains the viewpoint that they should be pure. The fundamental difference is that in CQRS objects are split into two objects, one containing the Commands one containing the Queries.

コマンドとクエリの責任の分離は、Meyer氏が使用していたものと同じ定義を使用しており、純粋なものであるべきという視点を維持しています。根本的な違いは、CQRSではオブジェクトが2つのオブジェクトに分割され、1つはコマンドを含むオブジェクト、もう1つはクエリを含むオブジェクトに分割されます。

ここだけ読むと「そうかオブジェクトを分ければいいだけか」となりますが、

The Query Side

クエリ側

After CQRS has been applied there is a natural boundary. Separate paths have been made explicit. It makes a lot of sense now to not use the domain to project DTOs. Instead it is possible to introduce a new way of projecting DTOs

CQRSを適用した後には、自然な境界があります。別々のパスが明示されています。DTOを投影するためにドメインを使用しないことは、今では非常に理にかなっています。その代わりに、DTOを投影する新しい方法を導入することができます。

ドメインを利用するコマンド側とDTOを利用するクエリ側には境界があるとされている。原義のPDFでも大半の部分でこの隔離法を説いている。以下は抜粋。

In the “Stereotypical Architecture” the domain was handling both Commands and Queries, this caused many issues within the domain itself.

ステレオタイプのアーキテクチャでは、ドメインはコマンドとクエリの両方を処理していたため、ドメイン自体に多くの問題が発生しました。

Once the read layer has been separated the domain will only focus on the processing of Commands. These issues also suddenly go away. Domain objects suddenly no longer have a need to expose internal state, repositories have very few if any query methods aside from GetById, and a more behavioral focus can be had on Aggregate boundaries.

読み取り層が分離されると、ドメインはCommandsの処理のみに集中するようになります。これらの問題も突然なくなります。ドメインオブジェクトは突然内部状態を公開する必要がなくなり、リポジトリにはGetById以外のクエリメソッドがある場合はほとんどありません。

まとめると、モジュールレベルでCとQが分かれているということです。簡単にCQRSとは何かを説明するなら以下となる。

CQRSはCモジュールとQモジュールを完全に分離というより隔離。お互いに実装レベルでも知識レベルでも依存してはいけない。その上で中継役としての第3のモジュールで統合する。これに該当しないものはCQRSにあらず。モデルだけ分けるがCQRSじゃない
— かとじゅん (@j5ik2o) 2020年9月17日

たぶん、C/Qをモジュールとして隔離しなくてもモデルだけ分ければいい派はいるでしょう。いてもいいですが、僕はそれを原義に照らしてCQRSと言ったらダメでしょう派です。GregさんがSegregationという強い言葉をわざわざ選んだ理由を考えるべき。

モデルを分ける・メソッドを分ける部分だけを初歩のCQRSと理解している派いそうですがSeparation(分離)じゃなくSegregation(隔離)ですよ。モデルを分ける程度ならこんな強い言葉使う必要ない。CQSでいい。原義の大部分でもこの隔離法を説いている。モジュール分割レベルで理解することが妥当だと思う
— かとじゅん (@j5ik2o) 2020年9月17日

原義をこのように理解しているが、このままで終わると原理主義と言われるので、次の記事で背理法的にモジュール分割せずにモデルだけ分ける立場でそれが、なぜ良い設計にならないか書いてみよう。

具体的な実装コードからEvent Sourcingを理解する

2020-09-16T16:20:37+09:00

DDD Community JPのほうでCQRS/Event Sourcingについて少し盛り上がったので、どういう議論をしたかまとめるのと同時に補足も追加しました。ちなみに、Event Sourcingが主題ですが、CQRSも前提として関係します。その想定で読んでいただければと。

発端はこのツイート。

これはEvent Sourcingじゃないと無理ですね。状態に基づく限り、ストリーム処理は難しいです https://t.co/prB16GJC5q
— かとじゅん (@j5ik2o) 2020年9月14日

僕が引用したツイートは松岡さんの質問箱に対するリアクションです。その質問箱に寄せられた質問は以下。

ストリームを開いてから閉じるまでのデータが変化する毎にUIで表示したい場合、DDDではどのように設計したら良いでしょうか？ DDDのリポジトリは1つのリクエストに対して1つのリクエストを返すイメージがあり、ストリームをどのような形で扱ったら良いのかつかめずにいます。

かなり抽象的な質問なのでいろいろ確認しないとわからないのですが、CQRS/Event Sourcingならどう解決するか考えてみました。こういった説明が抽象的でわかりにくいという声をよく聞くので、具体的なコード*1を交えた説明になっています。注意事項としては、CQRS/Event Sourcingには実装コストが掛かります*2。それほどのコストを掛ける価値があるシステムなのかよく考えてくださいというのは前提としてありますので、その点は注意して読んでください。

CRUDは最新状態に基づく設計スタイル

ドメイン駆動設計を前提にAPIサーバなどを設計した場合、APIはリクエスト・レスポンスでCRUDすることが多いです。この場合、アプリケーション内部でリポジトリを使ってドメインオブジェクトを取り出すロジックになるのでリポジトリ操作もリクエスト・レスポンスに対応します。そしてCRUDは最新状態に基づく設計スタイルです。

ショッピングカート*3に商品を追加するユースケースで考えると以下のようになります。ビジネスルールを守るのがドメインオブジェクトで重要な役割を持っています。

class AddCartItemUseCase(cartRepository: CartRepository) {

  def execute(cartId: CartId, itemId: ItemId, num: ItemNum): Unit = {
    // 最新の集約(グローバルなエンティティ)をストレージから取得する
    val cart = cartRepository.findById(cartId)
    // ロジック実行: 予算超過ならカートオブジェクトが商品の追加を拒否する！
    val newCart = cart.addItem(itemId, num)
    // 更新された最新状態をストレージに保存する
    cartRepository.store(newCart)
  }

}

カート内の商品を取得するユースケースは以下のようになるでしょう。

class GetCartItemsUseCase(cartRepository: CartRepository) {

  def execute(userAccountId: UserAccountId): Vector[CartItem] = {
     cartRepository.findByUserAccountId(userAccountId).map{ cart => cart.items }
  }

}

質問にあったように、リクエストに対してレスポンスを返すスタイルになっています。いわゆるPULL側のAPIです。REST APIであればこれで何ら問題でしょう。

イベントをPub/Subする

今回の質問は、ストリーム接続したいということです。漠然と「ストリームで」という話ですが、扱うデータは何でしょうか。上記の質問の場合は、ドメインの最新状態をリクエスト・レスポンス型で返しますが、ストリームでは最新状態を返すのでしょうか？ほとんどケースではそうではなく、そのとき起こった出来事であるイベントをクライアントに返すことになります。

例えば、上記のAddCartItemUseCase#executeが実行されると、商品追加イベントが発生し、ストリームに接続するクライアントにそのイベントが通知されるという具合になります。サーバからクライアントへデータがPUSHされる形になり、通常はストリームの接続は永続的になります。

サーバ側のエンドポイントの実装ではイベントのサブスクライバを作ります。サブスクライバでカートイベントを受信したら、ストリームに流すだけです。以下はakka-httpでSSE(Server Sent Event)を行う場合の例です。イベントどのサーバからでも受信できるようにストレージからWrite/Readすることになると思います。

path("events" / LongNumber ) { cartId =>
    get {
      complete {
        cartEventSubscriber.subscribe(cartId)
          .map(event => ServerSentEvent(event))
          .keepAlive(1.second, () => ServerSentEvent.heartbeat)
      }
    }
  }

さて、ドメイン状態が変化したときに、イベントをパブリッシュする実装はどうしたらよいか。ユースケースから上記で説明したストレージへイベントを書き込むことになると思います。

// CRUD前提のユースケース実装
class AddCartItemUseCase(cartRepository: CartRepository) {

  def execute(cartId: CartId, itemId: ItemId, num: ItemNum): Unit = {
    val cart = cartRepository.findById(cartId)
    val newCart = cart.addItem(itemId, num)
    cartRepository.store(newCart) // (1)
    cartEventService.publish(CartItemAddedEvent(cartId, itemId, num)) // (2)
  }

}

これはいわゆるPub/Subの仕組みです。で、勘違いされている方が多いのですが、CQRS/Event Sourcingとは直接関係ないです。混同しないようにしましょう。上記はイベントを送受信しているだけでCQRS/Event Sourcingではありません。

ところで、上記コードの(1)の状態更新に加え(2)のイベントの書き込みが増えたわけですが、ここで違和感を覚えます。(1)と(2)ってストレージがまず違うので同一トランザクションにできません。つまり2相コミットとかダブルコミットというやつです。不整合が起きた場合、リカバリが面倒なやつです。例えば、(1)がコミットされたあとに、(2)が失敗したらどうなるか。(1)の完了した書き込みを削除するか、(2)の書き込みが成功するまでリトライするかです。複雑なリカバリ処理を自前で実装するハメになります。

ダブルコミットは避ける

なので、ダブルコミットはできる限り避けましょうです。以下は古典ですが読むことをお勧めします。

ameblo.jp

CQRS/Event Sourcingの考案者であるGregさんもダブルコミットを推奨していないようです：(興味あればこちらも参照ください)

The two-phase commit can be expensive but for low latency systems there is a larger problem when dealing with this situation. Generally the queue itself is persistent so the event becomes written on disk twice in the two-phase commit, once to the Event Storage and once to the persistent queue. Given for most systems having dual writes is not that important but if you have low latency requirements it can become quite an expensive operation as it will also force seeks on the disk.

”二相コミットはコストがかかりますが、低レイテンシのシステムでは、この状況を扱う際にはより大きな問題があります。一般的に、キュー自体は永続的なので、イベントは二段階のコミットで二度ディスク上に書き込まれます。ほとんどのシステムでは、二重書き込みを行うことはそれほど重要ではありませんが、もし低レイテンシの要件がある場合には、ディスク上でのシークを強制的に行うことになるため、非常に高価な操作になる可能性があります。”

The database would insure that the values of sequence number would be unique and incrementing, this can be easily done using an auto-incrementing type. Because the values are unique and incrementing a secondary process can chase the Events table, publishing the events off to their queue. The chasing process would simply have to store the value of the sequence number of the last event it had processed, it could even update this value with a two-phase commit bringing the update and the publish to the queue into the same transaction.

”データベースは、シーケンス番号の値が一意でインクリメントされることを保証しますが、これはAUTO INCREMENT型を使用して簡単に行うことができます。値が一意でインクリメントされているので、セカンダリプロセスはイベントテーブルを追いかけることができ、イベントをキューに公開することができます。追いかけるプロセスは、単に最後に処理したイベントのシーケンス番号の値を保存しておく必要があります。この値を更新するには、二段階のコミットで更新とキューへの公開を同じトランザクションにすることもできます。”

ではどうしたらよいか。(1)と(2)は同時に二つ処理せずに、(2)のイベントだけを書き込むようにします。(1)の状態は(2)のイベントを基に別のプロセスで作り出します。これがCQRS/Event Sourcingで、すべての状態はイベントから導出できるようにします。やっと本題。

しかし、以下の(0)から(1)の処理は、最新状態に基づいているのでそのままでは使えません。設計を見直す必要があります。

def addCartItem(cartId: CartId, itemId: ItemId, num: ItemNum): Unit = {
  // val cart = cartRepository.findById(cartId) // (0)
  // val newCart = cart.addItem(itemId, num)
  // cartRepository.store(newCart) // (1)
  // イベントの書き込みはこれでよいが、↑の処理をどうしたらよいか 
  cartEventService.publish(ItemAdded(cartId, itemId, num)) // (2)
}

Event Sourcingでプログラミングモデルがどう変わるか

前述しましたが、CQRS/Event Sourcingは、簡単にいうとイベントから状態を導出するアーキテクチャです。絵で説明したほうがわかりやすいので結論となる図は以下。どーん。「え、複雑だなぁ」と思いますよね。単純なCRUDよりはそりゃ難しくなりますよ…。その代わり耐障害性やスケーラビリティが向上するのです…。一つのアプリケーションのように見えますが、コマンド側とクエリ側は分離してデプロイすることが可能です。

イベントからドメインオブジェクトをリプレイする

ジャーナルDBと呼ばれるデータベースに、カートオブジェクトが発行したカートのイベント(以下、カートイベント)が永続化されます。このイベントを使ってコマンド側にドメインオブジェクトを、クエリ側にリードモデルを構築します。(リードモデルの形式は何でもOKです。リードDBはジャーナルDBと物理的に分けるかどうかはここでは問いません。まず概念的に理解したほうがいいでしょう)。つまり状態といえるものが2種類あるわけです。リードモデルは後述しますが、まずはドメインオブジェクトから。

以下のように、永続された複数のイベントがあれば、最新のカートオブジェクトを作る(リプレイ)ことが可能です。(1)の部分でイベントを読み込み、(2)で最新のカートオブジェクトを作り出します。

def addCartItem(cartId: CartId, itemId: ItemId, num: ItemNum): Unit = {
  val allEvents = cartEventService.getAllEventsById(cartId) // (1)
  val cart = replayFunction(allEvents) // (2)
  val itemAdded = cart.addItem(itemId, num)
  cartEventService.publish(itemAdded)
}

スナップショットでリプレイ時間を短縮する

前述のコードみてこれはひどい設計だと思ったのではないでしょうか。わかります。僕も最初そう思いました…。容易に想像がつきますが、永続化されたカートイベントの件数に比例してリプレイのパフォーマンスが悪化します。なので、対策として、永続化するイベントN件ごとにカートオブジェクトの状態をスナップショットDBに保存しておき、カートオブジェクトをリプレイする際に、最新スナップショット＋それ以降に発生した差分イベントを読み込んで、高速にリプレイします。つまり、N件以上イベントがあっても、最新のスナップショットと最大N - 1件分の読み込みで済ませることができます。とはいえ、Nを小さくすると読み込む差分イベントが少なくなる一方でイベント書き込み時のスナップショットを更新する頻度も高くなります。諸刃の剣ではありますが、バランスをうまくとる必要があります。Akka(akka-persistence)でもサポートされている機能でS3やDynamoDBをスナップショットDBとして使うことができます。

以上のことを踏まえると以下のようなイメージになります。前提としてイベントやスナップショットには連番(seqNr)が振ってあるものとします。まず、最新のスナップショットとそのスナップショットのseqNr以降の差分イベントを取得します。それらを使って最新のカートオブジェクトをリプレイします。そしてオブジェクトオブジェクトの振る舞いを実行します。新しいカートオブジェクト、イベントを得ます。イベントはエンキューされますが、seqNrが1000件で割り切れるときに新しいカートオブジェクトを最新のスナップショットとして保存します。

def addCartItem(cartId: CartId, itemId: ItemId, num: ItemNum): Unit = {
  val snapshot = loadSnapshot(cartId)
  val events = cartEventService.getEventsByIdWithSeqNr(cartId, snapshot.seqNr + 1)
  val cart = replayFunction(snapshot, events)
  val (newCart, itemAdded) = cart.addItem(itemId, num)
  seqNr += 1
  if (seqNr % 1000 == 0 ) {
    saveSnapshot(newCart, seqNr)
  }
  cartEventService.publish(itemAdded, seqNr)
}

こうすることでリプレイ時間を短縮化できますが、CRUDのときと比較すると多くのデータを読み込んでいることがわかりますね…。もう少し効率的にならないかについては後ほど説明します。

追記:

ドメインオブジェクトはいちいちイベントからリプレイせずに、クエリ側のリードモデルをユースケースでうまく使えないの？と思うかもしれませんが、以下の問題があり難しいです。

非正規化されたリードモデルは正規化されたドメインモデルではないので、代替はそもそも難しい。代替したとしたらDDDではなくなりそう
C/Qがモジュールとして分離できなくなる。CとQが分離されていないならもはやCQRSではない？違う呼び方がよさそうです。
リードDBへの書き込み時間分、最新状態を取得する時間が遅延する。つまり常に過去のデータをみていることになってしまいます。これは許容できる場合がありそう、要件によりますね

リードモデルの構築

コマンド側のドメインモデルの概要はつかめたと思いますが、クエリ側のリードモデルを考えてみましょう。

このアーキテクチャパターンによって、イベントが唯一信頼できるデータソースとなり、そのイベントを基にクエリ側のリードモデルを構築します。イベントは不変という特徴を持ちます。なので、いつでも正しいリードモデルを作り出せます。極端な話、リードモデルの設計をミスってもイベントから作り直せます。もちろん、データ更新コストはかかりますが…。

コマンドとクエリで要件が非対称

そもそもなぜコマンドとクエリでモデルを分離するのか。理由は以下の表を参照してください。つまるところ要件が違うからです。人間が閲覧するようなシステム(SoEは特に顕著)だとまずクエリ側は非正規化データを求めます。

-	コマンド	クエリ
一貫性/可用性	トランザクション整合性を使い一貫性を重視する	結果整合を使い可用性を重視する
データ構造	トランザクション処理を行い正規化されたデータを保存することが好まれる(集約単位など)	非正規化したデータ形式を取得することが好まれる(クライント都合のレスポンスなど)
スケーラビリティ	全体のリクエスト比率とごく少数のトランザクション処理しかしない。必ずしもスケーラビリティは重要ではない	全体のかなりのリクエスト比率を占める処理を行うため、クエリ側はスケーラビリティが重要

例えば、以下のような集約(グローバルなエンティティ)がある場合でも

Employee { id, name, deptId }
Department { id, name }

画面は以下のように集約を二つ結合したようなデータを求めます。deptIdだけではどの部署か分からないから名前も必要なのです。*4

Employee { id, name, deptId, deptName }

ドメインオブジェクトの構造にインパクトを与えるのは、このような正規と非正規の構造的な非対称性です。考えてみるとわかりますが、トランザクション処理と検索・レポートを両立するモデルの実現も理解も難しいのです。

さて、コマンドとクエリを分離しないと実装上でどんな問題が起きるか気になるところですが、以下のようなものがあります。

リポジトリのクエリメソッドが複雑になる
N+1クエリが発生しやすい
ドメインオブジェクトからDTOへの変換が非効率

簡単に以下に説明します。

クエリ要件をリポジトリで満たそうとしてメソッドが複雑になる

集約(グローバルなエンティティ)は識別のためにIDを持つため、IDから集約本体を引き当てることができます。これはある意味正引きです。

val employee = employeeRepository.findById(employeeId)

しかし、集約の他の属性(名前や他のIDなど)を使って集約(単体もしくは複数)を引き当てたい場合があります。セカンダリインデックスを使うような逆引きですね。

以下のようなコードを書いたことがありませんか？僕は散々書いてきました。

val employees = employeeRepository
  .findByDeptIdsWithEmpNamePatterns(deptIds, empNamePatterns)

ドメインの振る舞いを起こすためというより、クライアントにクエリのレスポンスを返すためによく使っていました。これは本当にドメインの責務でしょうか。ドメインは振る舞いを起こすことが責務と捉えると、ドメインの振る舞いが伴わないこのようなリポジトリメソッドは関心が分離できていないのかもしれません。前述した GetCartItemsUseCaseクラスの実装も本当にリポジトリの責務でいいか考える必要がありそうです。本当に集約をそのまま返すならば問題ないかもしれません。次のN+1クエリを含むような問題に発展する可能性がある場合は要注意です。

リポジトリでレスポンスを組み立てるとN+1クエリが発生しやすい

APIのレスポンスでは非正規化データを返すことがほとんどです。例えば、ホテルの予約情報一覧を作るために、予約集約に関連するホテル集約、顧客集約を解決しなければならないことがあります。ここでもドメインの振る舞いは起きません。クエリだからです。これは本当にリポジトリがやるべき仕事でしょうか。僕は過去にDBAに申し訳ないと思いながらこういうN+1が大量に発生するコードを書いていました…。そもそもレスポンスとして表形式を期待するならSQLとRDBにやらせるべきではないでしょうか。

reservationRepository.findByIds(ids).map { reservation => 
  val hotel = hotelRepository.findById(reservation.hotelId)
  val customer = customerRepository.findById(reservation.customerId)
  new ReservationDto(reservation, hotel.name, customer.name)
}

ドメインオブジェクトからDTOへの変換が非効率

APIのレスポンスでは集約の一部だけを求めることがあります。以下は恣意的な例ですが、UIに併せて顧客名一覧を返す処理です。リポジトリで得た集約の大部分を捨てて名前だけのリストを作ります。クエリ要件を満たすために大部分のリード結果が捨てられることになります。

val customerNames = customerRepository.findByIds(ids).map { customer =>
  customer.name
}

もちろん、概念モデルの粒度が大きいとI/Oコストも比例して大きくなるので、まず先に概念の大きさに目を向けるべきですが、コマンド側のドメインでクエリを頑張りすぎるとこういうことになります。

イベントからリードモデルを作る

RDBにリードモデルを構築するなら、以下のように永続化されたイベントを受信して、SQLを実行するだけです(実際にはこのようなストリーム処理は単発ではなく後に発生するワークロードに備えて常時起動させる必要があります)。これはこれで簡単ですが、cartIdを指定して読み込むので、スケールしにくいです。具体的なIDを指定しないので、ある程度の並列度を維持し永続化されたイベントを全順序に読み込む必要があります。また、こういった動作をするコンシューマは障害発生時のリバランスが必要になります。僕のお勧めはKafkaを使うことです。これはこれで一本ブログ記事が書けるぐらいの知識量なので、別の機会に触れます。

cartEventSubscriber.subscribe(cartId).runWith(Sink.foreach{
  case e: CartCreated => insertCartTable(e)
  case e: CartItemAdded => insertCartItemTable(e)
  case e: CartItemNumUpdated => updateCartItemTable(e)
  case e: CartItemRemoved => deleteCartItemTable(e)
  case e: CartRemoved => deleteCartTable(e)
})

まとめ。そして課題はまだある

ということでだいたいの雰囲気はつかめたのではないかと思います。とはいえ実装するうえではまだ課題があります。

たとえば、addCartItem内部の処理をもう少し効率化できないかの課題については、まさに分散システムの問題に直面します。

考えられる対策としては、カートオブジェクトをユースケースのスコープから外に出して、ワークロードがある間だけ起動させてキャッシュさせておく方法があります。リクエストごとに集約をリプレイしなくなるのでオーハーヘッドが軽減します。が、これは自前で実装するのは大変です。たとえば、ウェブサーバがスケールアウトして、ロードバランサから同じカートID向けの異なるリクエストが、複数サーバに飛んだこと想定してみてください。同一カートオブジェクトが別々のサーバでリプレイされ、異なるコマンドが受理されることで、同一IDなのに別々の状態が作り出されてしまいます。ある意味スプリットブレインな状態になります。

下図はイメージなので全然正確じゃないという前提ですが、前述のようなスプリットブレインにならないようにするには、集約(グローバルなエンティティ)を以下のようにシャーディングして、コマンドをルーティングするとよいわけです。つまり、同一IDの集約はクラスタ全体で1個しかないように配置すればよいでしょう…。クラスタ上で脳みそが一つしかないのでスプリットしようがないという話です。と、ここまで考えてめちゃくちゃ大変だと想像できたと思います。さらにサーバが故障した場合に別サーバに集約をテイクオーバさせるなど自前で実装したくない…。なので、AkkaやErlangなど分散システムのフレームワークなしでこういうことは辞めましょう…。AkkaではActorという軽量プロセスをクラスタ上に分散させることができます。こういう基盤なしに無茶は辞めよう…。*5

興味があれば以下参照。

akka.io

Akka実践バイブルアクターモデルによる並行・分散システムの実現

作者:レイモンド・ロステンバーグ,ロブ・バッカー,ロブ・ウィリアムズ,前出祐吾,根来和輝,釘屋二郎
発売日: 2017/12/13
メディア: Kindle版

正直この分野は沼感がありますが、参考になれば幸いです。

*1:とはいっても概念を説明するための疑似コードだと思ってください

*2:CQRS/Event Sourcingそのものというより、分散システムに起因する難しさですが…

*3:データベースに永続化される前提のカートと思ってください

*4:システムがユースケースのアクターならこういう考慮はいらないと思いますが、SoEだとどうしてもこういう要求は発生します

*5:分散システムに関係する話は途端に難しくなりがち。わかりやすく書いたつもりですが、十分に伝わらないかもしれません…ご容赦を…

外部キー制約は何も考えずに適用するとよくない

2020-06-16T10:53:11+09:00

このブログが話題になってますね。制約を付けること自体はよいことだけど、~~無目的に適用すると害も生じると思います。~~ 無目的という言い方はおかしいな…。外部キー制約をどのように使えばいいのか、逆にどんなときに使うとまずいのかを考えてみたいと思います。

tech.tabechoku.com

例えば、これ。外部キー制約はできるだけ付けるとか、何も考えずに付けるとよくないと思います。

外部キー制約は、可能な限りつけるようにしています。 DBが別れている場合、外部キーはもちろん貼れないのですが、そうでない場合はとにかく何も考えず貼っています。
データベース設計の際に気をつけていること - 食べチョク開発者ブログ

テーブル設計をシミュレーションする

いいたいことの結論はこれ。以上終了なのですが、もう少しわかりやすく書いてみよう。

何も考えずに外部キーを貼るのは良くないな。トランザクション境界の外で結果整合性を使う場合は、外部制約はつけない。つける場合は一緒に削除されるものに限定する。つまるところ更新の境界の外と内を意識してる / “データベース設計の際に気をつけていること - 食べチョ…” https://t.co/1L7sKxrlFQ
— かとじゅん (@j5ik2o) 2020年6月15日

テーブル設計

以下のテーブルがあるとします。商品の売上を管理するテーブルです。とりあえず、何も考えずに外部キー制約をすべてに適用しています。(論理削除ではなく一旦物理削除で考えましょう。論理削除はこういった境界分析の邪魔になりますので)

売上テーブル
- 売上ID(PK)
- 売上日時
売上詳細テーブル
- 売上詳細ID(PK)
- 売上ID(FK)
- 商品ID(FK)
- 数量
商品テーブル
- 商品ID(PK)
- 商品名
- 単価

想定ユースケース

商品情報を登録・更新・削除する
売上を登録・更新・削除する
- 売上には売れた商品、数量、金額の売上詳細の概念が含まれる

強い整合性と弱い整合性

ユースケースから考えて、整合性の境界を考えます。整合性には強いものと弱いものがあります。強い整合性は作成・更新・削除するときに一緒に行います。これは「トランザクション整合性」と呼ばれることがあります。弱い整合性は「結果整合性」と呼ばれることがあります。では、上記のテーブルで考えていきます。上記の図の点線はこの整合性の境界範囲を示しています。仮に全部が一つの境界内にあると考えシミュレーションします。

売上・売上詳細のトランザクション境界と外部キー制約

売上を登録するときに、一緒に個々の売上詳細を登録・更新・削除(物理削除)します。トランザクション整合性の境界(トランザクション境界)はどこからどこまでがよいでしょうか。売上には売上詳細の概念が含まれるとしているので、売上と売上詳細は同じ境界のほうが都合がよさそうです。つまり、売上と売上詳細が更新されるときは別個ではなく、不可分な一塊として扱われます。例えば、売上が先に作られて、売上詳細が後から作られることはありません。売上詳細だけが先に削除されることもなく、一緒に削除されます。

さて、売上と売上詳細は不可分な一塊です。ある売上詳細Aが存在するとき、参照する売上Bは必ず存在します。つまり売上詳細Aの売上ID(FK)は存在する売上BのIDを参照します。売上Bが存在しないとき売上詳細Aも存在しません。この外部キー制約は機能しそうですね。データを保護できそうです。

売上・売上詳細と商品は同じトランザクション境界か？

ここからが問題です。商品ID(FK)はどうなんでしょうか。ここに外部キー制約があっても本当に大丈夫でしょうか？ユースケースを見るかぎり、商品と売上(売上詳細を含む)は別々に作成・更新・削除されます。存在する売上詳細Aが削除されるとき、参照する商品Aはまだ削除されません。~~売上詳細Aの商品ID(FK)から商品AのIDに外部キー制約があると、売上詳細Aは削除できません。また、~~ ←(この表現は間違いでした。参照している側は削除できますね) 。外部キー制約の関係上、売上詳細が存在することで、商品単体での削除ができません。ユースケースを満たさなくなるので、同じトランザクション境界にできません。(え、普通は商品は削除しないだろうがという方、分かります。とりあえず最後まで読んでほしい)

なので、以下のように境界が別個になるはずですが、外部キー制約があるほうが問題になります。

整合性境界は物理削除で考えたほうがラク

「論理削除なら整合性の境界とか考える必要ないのでは？」という想定質問があるのですが、そんなことはないです。論理削除でも更新する境界がどこからどこまでかを考える必要があります。売上を消したつもりが商品も消されたら問題ですから。削除フラグが連動する範囲が整合性の境界になります。しかし、これを頭の中で整理して考えることが難しい。なので、分析時は物理削除で考えたほうが圧倒的にラクです。

売上・売上詳細と商品は結果整合性を使う

ということで、この場合どう考えるとよいか。トランザクション境界が異なるということはライフサイクルの境界が異なるわけです。売上詳細から参照する商品IDは存在するかもしれないし、すでに削除されているかもしれません。こういった弱い整合性を結果整合性といいます。ここには外部キー制約は適用できません。

また、アプリケーションロジックで以下の売上合計金額を算出する場合、売上詳細からみて商品が結果整合性では、再計算できなくなってしまいます。

売上合計金額=すべての売上詳細金額の合計
売上詳細金額=商品IDの単価×数量

これに対処するには、売上・売上詳細の境界内に再計算するための材料を保持する必要があります。もしくは計算結果を保持する方法もありそうですね。前者だとしたら、更新時にそのときの商品IDの単価をコピーする必要があります。(場合によっては商品名が更新されたり削除されるかもしれないので、商品名のコピーも必要になるかもしれません)

売上テーブル
- 売上ID(PK)
- 売上日時
売上詳細テーブル
- 売上詳細ID(PK)
- 売上ID(FK)
- 商品ID(※)
- 単価(※)
- 数量
商品テーブル
- 商品ID(PK)
- 商品名
- 単価

これは集約という考え方

このような考え方は、ドメイン駆動設計の集約 を学ぶとわかるようになるはずです。今回はテーブル設計の視点から説明してみましたが、ドメインモデルが整合性の境界を持つと考えるとわかりやすくなるかも。DDDの観点で簡単に言えば、強い整合性境界である集約の内側では外部キー制約に意味があり、集約の外には外部キー制約は不要です。興味がある方はぜひ学んでみたらいいと思います。

エリック・エヴァンスのドメイン駆動設計

作者:Eric Evans
発売日: 2013/11/20
メディア: Kindle版

実践ドメイン駆動設計

作者:ヴァーン・ヴァーノン
発売日: 2015/03/19
メディア: Kindle版

ということで、整合性の境界を無視して、外部キー制約を適用することはできません、ということで。

併せて読みたい:

kbigwheel.hateblo.jp

追記:

ブコメで例が悪いと指摘があったので、少し再考してみた。わかりにくいことは認める。言いたいことは結果整合性を求める用途では外部キー制約は使えない。トランザクション整合性のある境界内では使えるという主張だった。

で、商品＝今使える商品という意味で捉えてほしい。商品が廃盤になるとやはり物理削除して、過去に使えてた商品テーブルに移動するかもしれない。実際は、こんな難しいことをせずに、商品は削除せずに「廃盤状態」に遷移できるようにする方法もある。が、何が正しいかは要件による。ここでは仕様の善し悪しを議論したいわけではなく、仮に商品を消すことがある場合、売上詳細から商品ID(FK)は強い整合性を望むので使えないという意図だった。つまるところ、ライフサイクルの境界が異なるのだから、商品IDから商品に到達できるかはそのとき次第なので、以下のような考慮が必要かもしれない、ということ。

商品IDだけでは困るケースがある。例えば、商品が廃盤になったり、単価改定など。過去に作った売上が変わってしまう。ライフサイクルが異なるので起きる。これを想定するなら、売上詳細側に商品名や単価などを取り込まないといけない https://t.co/tNSZJ5XgmB
— かとじゅん (@j5ik2o) 2020年6月17日

とはいえ、もっとよい事例はないかと考えた。Slackのようなチャットサービスで、あるアカウントが投稿したメッセージは他のアカウントでも読める。しかし、ある投稿者のアカウントIDが退会したケースを考えてみよう。忘れられる権利に対応するために、アカウントは物理削除しなければならないとする(物理削除好きやな。まぁ例示のための仮定です)。しかし、退会アカウントのメッセージはタイムラインで、”退会済みアカウント”が投稿したメッセージとして、他のアカウントから閲覧できるものとする。この場合でも、メッセージとアカウントはライフサイクル、整合性の境界が独立している。メッセージからみてアカウントはあるかもしれないしないかもしれない。弱い整合性。この場合は、メッセージのアカウントIDからアカウントのアカウントIDに外部キー制約は適用できない。

アカウント
- アカウントID(PK)
- メールアドレスなどの個人情報など
メッセージ
- メッセージID(PK)
- スレッドID
- メッセージ内容
- アカウントID(必ずしも存在するとは言えないので、外部キー制約は適用できない)
- 作成日時
- 更新日時

CQRS/ESによって集約の境界定義を見直す

2020-06-13T17:54:48+09:00

peing.net

メッセージングシステムのお題のようです。面白そうなのでちょっと考えてみよう。

問題提起

集約候補が以下の3つ。

ユーザー
企業
スレッド
- メッセージ

スレッド集約はメッセージを複数保持するようです。

1000件のメッセージを保持するスレッド集約を更新した際、1000件のアップデートが行われる
スレッド集約内部で更新された属性を把握していない場合は、リポジトリでは全メッセージ分の更新となる。これを避けるための仕組みはどう実装するのか？

ということが指摘されている。まぁわかります。これはCQRS/ESなら解決できるよと言ってみる

問題の分析

で、僕ならどう考えて実装に落とすかつらつらまとめてみよう。CQRS/ES前提です。Akkaの成分は少なめでScalaの擬似コードで解説します。コードはコンパイルしてないので…おかしなところあるかも。

問題はスレッド集約がメッセージの集合を保持した場合、更新コストが大きくなりがち。さらに差分更新しようとしても集約の内部実装が複雑になるのではという論点。

まず考えるのは、スレッドとメッセージの関係性に強い整合性は必要か？ ということです。Noならメッセージを別の集約として切り出すのがよいとは思います。おそらく問題設定としてはYesになっている気がしますが…。仮に契約プランによって書き込めるメッセージ数が変わるという場合は、スレッドとメッセージには強い整合性が必要かもしれません。別別の集約にした場合、トランザクションが別になり結果整合性になるため、インスタンス数(レコード数)を厳密に制御することはできませんね。ということで、強い整合性が必要という前提で進めます。

あと、この問題だけではスレッド集約がどのような使われ方をするのが厳密にはわかりません。つまり振る舞いがイメージできません。たとえば、スレッドにメンバーとして参加したアカウントだけがメッセージを閲覧・追加・更新できるというシナリオがあればスレッド集約の構造が明確になります。メンバーの考慮が必要なスレッド集約は以下のようなイメージになるでしょう。

case class Message(id: MessageId, text: MessageText, senderId: AccountId, createdAt: Instant, updatedAt: Instant)

case class Messages(values: List[Message]) {
  def add(message: Message): Messages = ???
  def update(message: Message): Messages = ???
}

case class Members(values: List[AccountId]) {
  def add(accountId: AccountId): Members = ???
  def remove(accountId: AccountId): Members = ???
  def contains(accountId: AccountId): Boolean = ???
}


class Thread(id: ThreadId, members: Members, messages: Messages, createdAt: Instant) {

  def addMember(account: AccountId): Thread = copy(members = members.add(accountId))

  def addMessage(messageId: MessageId, messageText: MessageText, senderId: AccountId): Either[ThreadError, Thread] = { 
    if (members.contains(senderId)) {
      Right(copy(messages = messages.add(Message(messageId, messageText, senderId, Instant.now, Instant.now))))
    } else {
      Left(new AddMessageError)
    }
  }
    
  def updateMessage(messageId: MessageId, messageText: MessageText, sender: AccountId): Either[ThreadError, Thread] = 
    if (members.contains(senderId)) {
      Right(copy(messages = messages.updateMessage(Message(messageId, messageText, senderId, Instant.now, Instant.now))))
    } else {
      Left(new UpdateMessageError)
    }
    
  def getMessages(accountId: Account): Either[ThreadError, Messages] = 
    if (members.contains(accountId)) {
      Right(messages)
    } else {
      Left(new ReadMessagesError)
    }

}

課題に戻りますが、このクラスをリポジトリでCRUDすることを想像してみましょう。thread.messagesが1000件ある場合です。

for {
thread <- threadRepository.findById(threadId)  // 1000件メッセージを持つスレッドを取得
newThread <- thread.addMessage(Message(...)) // 状態変更
_ <- thradRepository.store(newThread) // 1001件メッセージを持つスレッドを更新
} yield ()

スレッドのどのフィールドが更新されたかわからない場合は、スレッドのタイトル、説明、メッセージの本文などをすべての情報をSQLなどを使って更新するのでしょうか？これはあまりに非効率ではないか…。それを回避するにはThread集約内部にどのフィールドをDB上で更新すべきか把握する仕組みが必要なのではないかという話ですね。あと、そもそもfindByIdの時点で、本文も含む1000件のメッセージをDBから取得するのは効率がよいとはいえませんね。

CQRS/ES流の設計

上記の問題をCQRS/ESで改善できるか考えてみよう。

コマンド側

集約はCQRSのC(コマンド)側に所属しますが、役割は副作用を起こすことを目的にします。たとえば、メンバーの追加・削除、メッセージを追加・更新などです。メンバーの確認はメッセージの追加・更新に必要なので含めます。これら以外はクエリ側の責務とします。

class Thread(id: ThreadId, memberIds: MemberIds, messages: MessageIds, createdAt: Instant) {

  def addMember(account: AccountId): Thread = copy(members = memberIds.add(accountId))

  def addMessage(messageId: MessageId, messageText: MessageText, senderId: AccountId): Either[ThreadError, Thread] =
    if (memberIds.contains(senderId)) {
      Right(copy(messages = messageIds.add(mesageId)) // 本文は保存しない
    } else {
      Left(new AddMessageError)
    }
    
  def updateMessage(messageId: MessageId, messageText: MessageText, sender: AccountId): Either[ThreadError, Thread] = 
    if (memberIds.contains(senderId)) {
      Right(this) // スレッドではメッセージIDしか管理しないのでメッセージ本文を更新できない
    } else {
      Left(new UpdateMessageError)
    }
  

}

本文を持たないので大分軽量化できたのではないでしょうか？(ただ、内部にID集合は保持するので無限に保持するわけには行かないとは思います。上限値は必要だと思います) さて、クエリ側にどうやって連携するかですね。メッセージの本文も読めないと意味がないですからね。

ということで、擬似コードですが、以下のように副作用が起きたときにイベントをDBに追記します。このイベントは別のプロセスがコンシュームしてリードモデルを作る元ネタになります。

sealed trait ThreadEvent
case class MemeberAdded(threadId: ThreadId, accountId: AccountId, occurredAt: Instant) extends ThreadEvent
case class MessageAdded(threadId: ThreadId, messageId: MessageId, messageText: MesssageText, senderId: AccountId, occurredAt: Instant) extends ThreadEvent
case class MessageUpdated(threadId: ThreadId, messageId: MessageId, messageText: MesssageText, senderId: AccountId, occurredAt: Instant) extends ThreadEvent

class Thread(id: ThreadId, memberIds: MemberIds, messages: MessageIds, createdAt: Instant) {

  def addMember(accountId: AccountId): Thread = {
     persistEvent(MemberAdded(id, accountId, Instant.now))
     copy(members = memberIds.add(accountId))
   }

  def addMessage(messageId: MessageId, messageText: MessageText, senderId: AccountId): Either[ThreadError, Thread] =
    if (memberIds.contains(senderId)) {
      persistEvent(MessageAdded(id, messageId, messageText, senderId, Instant.now))
      Right(copy(messages = messageIds.add(mesageId))
    } else {
      Left(new AddMessageError)
    }
    
  def updateMessage(messageId: MessageId, messageText: MessageText, senderId: AccountId): Either[ThreadError, Thread] = 
    if (memberIds.contains(senderId)) {
      persistEvent(MessageUpdated(id, messageId, messageText, senderId, Instant.now))
      Right(this)
    } else {
      Left(new UpdateMessageError)
    }
  

}

書き込みはこれでよいとして、集約をDBから再生する際はどうなるのか。DBに保存してあるイベント列を順番に空のThreadに適用するだけです。これも疑似コードで説明。この考慮はあくまでコマンドを実行するための前提を整えるためのものです。

class Thread(id: ThreadId, events: Seq[ThreadEvent]) {

  private var memberIds: MemberIds = MemberIds.empty
  private var messages: MessageIds = MessageIds.empty

  // イベントから最新状態を復元
  events.foreach{
    case MemberAdded(_, accountId, _) => members = memberIds.add(accountId)
    case MessageAdded(_, messageId, messageText, senderId, createdAt) => messages = messages.add(Message(messageId, messageText, senderId, createdAt)
    case MessageUpdated(_, messageId, messageText, senderId, updatedAt) => messages = messages.update(Message(messageId, messageText, senderId, updatedAt)
  }


  def addMember(accountId: AccountId): Thread = {
     persistEvent(MemberAdded(id, accountId, Instant.now))
     copy(members = memberIds.add(accountId))
   }

  def addMessage(messageId: MessageId, messageText: MessageText, senderId: AccountId): Either[ThreadError, Thread] =
    if (memberIds.contains(senderId)) {
      persistEvent(MessageAdded(id, messageId, messageText, senderId, Instant.now))
      Right(copy(messages = messageIds.add(mesageId))
    } else {
      Left(new AddMessageError)
    }
    
  def updateMessage(messageId: MessageId, messageText: MessageText, senderId: AccountId): Either[ThreadError, Thread] = 
    if (memberIds.contains(senderId)) {
      persistEvent(MessageUpdated(id, messageId, messageText, senderId, Instant.now))
      Right(this)
    } else {
      Left(new UpdateMessageError)
    }
  

}

これでドメインを扱うコマンド側では、差分を表現するイベントをジャーナルとして追記保存すればいいことになります。また最新の集約の状態はコマンドを受け付けるために必要最低限のものしか持ちません。クエリをしないので、これで問題は起きません。当初想定していたモデルよりかなり小さくなります。コマンド側の集約はリプレイ後はルールをチェックしてパスしたらイベントを追記保存するだけなんです。

AkkaはEvent Sourcingを標準サポート

ここでは示してませんが、イベントの列が巨大だとリプレイに時間が掛かります。例えばイベントN件に1回スナップショットを保存しておき、リプレイ時に最新スナップショット+差分のイベントでリプレイを高速化することもできます。とはいえ、リクエストのたびにイベント列を読み込み・適用するのは効率が悪そうです。Akkaのアプローチでは軽量プロセスであるActorとしてスレッド集約を実装します。上記のクラスがActorとして実装されます(集約アクター)。メソッドコールがメッセージパッシングに変わります。すでにイベント列がある集約アクターはAkkaがストレージからイベントを読み込み、メッセージとして適用してくれます。また一定時間メッセージを受け付けていない集約アクターはランタイムから消えるように設定できます。まぁ、必要な機能が揃っているので確実に楽できます。

doc.akka.io

クエリ側の設計

クエリ側のリードモデルはどうやって作るのか？仮に上記のイベントがDynamoDBに書き込まれるとして、パーティションキーはThreadId, ソートキーはイベント番号(akkaでは自動採番してくれます)、イベント本体はJSONなどで格納されるイメージとします。これをDynamoDB Streamsなどでコンシュームします。コンシューム部分はLambdaでもKCLでもよいです。以下を参考にしてみてください。

docs.aws.amazon.com docs.aws.amazon.com

この方法でイベントが時系列順に手に入ります。リードモデルを作るにはこのイベントを順番にリードDBに反映します。仮にRDBにTHREADテーブル、MEMBERテーブル、MESSAGEテーブルがある場合は以下のような処理になります。 consumeEventsByThreadIdFromDDBStreamsはDynamoDB Streamsからレコードを読み込んでイベントを返す関数です。

consumeEventsByThreadIdFromDDBStreams.foreach{ 
  case ev: ThreadCreated => insertThread(ev) // 実際にはスレッドが作られたときのイベントも永続化する必要がある
  case ev: MemberAdded => insertMember(ev)
  case ev: MessageAdded => insertMessage(ev)
  case ev: MessageUpdated => updateMessage(ev)
}

最終的にリードモデルはレスポンスの形式に併せて定義するとよいでしょう。

case class ThreadDto(id: Long, ...)
case class MemberDto(id: Long, accountId: Long, createdAt: Int)
case class MessageDto(id: Long, threadId: Long, text: String, senderId: Long, createdAt: Instant, updatedAt: Instant)

リードモデルはDAO内部でSQLを使って、部分集合を取り出したりできます。リードモデルはお好きなように…。

val messages: Seq[MessageDto] = MessageDao.findAllByThreadIdWithOffsetLimit(threadId, 0, 100)

結局どうなるのか

最終的な疑似コードイメージです。 1000件のメッセージを保持するスレッドといってもIDしか持ちません。本文を持つより簡単にリプレイし一つのコマンドを付けて一つのイベントを永続化するだけです。1001件のメッセージは永続化しません。間違いなくスケールするのはこっちですね。

val thread = Thread(ThreadId(1L)) // 永続化されているイベント列があれば渡される。なければイベント列は空で作られる
thread.addMessage(...) // 1つのコマンドで1つのイベントが追記されるだけ。1001件も更新されません。

補足

上記の考え方がわかったとしても、CQRS/ESは自前でやるのは大変です。たとえば、以下の処理が複数のサーバで起こった場合、ロックがなくても大丈夫でしょうか？ダメそうですねｗそう書き込むためのトランザクション管理が必要なのです…。

val thread = Thread(ThreadId(1L))
thread.addMessage(...)

AkkaではThread部分がActorになりますが、複数のサーバで起動しても、ユニークになるように分散できます。つまり分散システム上で同じIDのActorがたかだか一つになるように配置してくれるので、トランザクションの問題は起きません。こういったことを考えると、CQRS/ESをサポートしたフレームワークやライブラリを使うほうが圧倒的に楽です。Akka お勧めです。

akka.io

Akka実践バイブルアクターモデルによる並行・分散システムの実現

作者:Raymond Roestenburg,Rob Bakker,Rob Williams
発売日: 2017/12/13
メディア: 単行本（ソフトカバー）

Error, Defect, Fault, Failureの定義と解釈

2020-03-09T16:40:24+09:00

移動しました。

https://zenn.dev/j5ik2o/articles/6c4dbab802c9701fd878

akka-cluster スプリットブレインリゾルバ OSS実装一覧

2019-06-16T00:30:23+09:00

Akkaクラスターがネットワーク分断に遭遇した場合に、UnreachableメンバーをDown状態に遷移させるためのリゾルバのOSS実装を以下にまとめる。

ちなみに、このリゾルバがない場合はUnreachableのままだとリーダアクションが取れずにクラスターが機能不全状態なる。かといってAutodownを有効にするとスプリットブレインが発生する可能性がある。これを解決するのがスプリットブレインリゾルバで商用版はLightbend社から提供されている。スプリットブレインリゾルバの仕様はこちら

git repo	stars	備考
TanUkkii007/akka-cluster-custom-downing	131	OldestAutoDowning, QuorumLeaderAutoDowning, MajorityLeaderAutoDowningに対応している。OldestAutoDowningには不具合があるようだ。要修正
mbilski/akka-reasonable-downing	85	Static QuorumによるDowningにしか対応していない
arnohaase/simple-akka-downing	16	static-quorum, keep-majority, keep-oldestに対応している
guangwenz/akka-down-resolver	5	Static QuorumによるDowningにしか対応していない

sbtでビルドしたDockerイメージをECRにプッシュする方法

2019-05-26T11:20:43+09:00

sbt-native-packagerとsbt-ecrを使って、ビルド→ECRログイン→ECRへのプッシュまで行います。

https://github.com/sbt/sbt-native-packager https://github.com/sbilinski/sbt-ecr

ECRを作成する

レジストリを作る。作成後以下のようなURIが取得できます。

123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/j5ik2o/thread-weaver-api-server

sbtプラグインの設定の設定

project/plugins.sbt

// ...
addSbtPlugin("com.mintbeans" % "sbt-ecr" % "0.14.1")

addSbtPlugin("com.typesafe.sbt" % "sbt-native-packager" % "1.3.10")
// ...

build.sbtの設定

repositoryNameは、上記で得られたURIのホスト名を除く文字列(j5ik2o/thread-weaver-api-server)を指定すること

import com.amazonaws.regions.{Region, Regions}

val ecrSettings = Seq(
  region           in Ecr := Region.getRegion(Regions.AP_NORTHEAST_1),
  repositoryName   in Ecr := "j5ik2o/thread-weaver-api-server",
  repositoryTags   in Ecr ++= Seq(version.value), // タグを付ける場合は指定する
  localDockerImage in Ecr := "j5ik2o/" + (packageName in Docker).value + ":" + (version in Docker).value,
  push in Ecr := ((push in Ecr) dependsOn (publishLocal in Docker, login in Ecr)).value
)

val `api-server` = (project in file("api-server"))
  .enablePlugins(AshScriptPlugin, JavaAgent, EcrPlugin)
  .settings(baseSettings)
  .settings(ecrSettings)
  .settings(
    name = "thread-weaver-api-server",
    dockerBaseImage := "adoptopenjdk/openjdk8:x86_64-alpine-jdk8u191-b12",
    maintainer in Docker := "Junichi Kato <j5ik2o@gmail.com>",
    dockerUpdateLatest := true,
    dockerUsername := Some("j5ik2o"),
    bashScriptExtraDefines ++= Seq(
      "addJava -Xms${JVM_HEAP_MIN:-1024m}",
      "addJava -Xmx${JVM_HEAP_MAX:-1024m}",
      "addJava -XX:MaxMetaspaceSize=${JVM_META_MAX:-512M}",
      "addJava ${JVM_GC_OPTIONS:--XX:+UseG1GC}",
      "addJava -Dconfig.resource=${CONFIG_RESOURCE:-application.conf}"
    ),
// ...
)

実行

profileを使う場合は以下のようにする

$ AWS_DEFAULT_PROFILE=xxxxx sbt api-server/ecr:push

Microsoft社のDDD, CQRSに関する記事一覧

2019-05-04T08:44:29+09:00

CQRS+ESパターンの説明

コマンドクエリ責務分離 (CQRS) パターン
- ステートソーシング(CRUD)の短所としてあげているもの
  - 読み取りと書き込みのデータ表現不一致問題
  - ステートの同時更新による競合問題
  - 読み取りと書き込みが同じモデルによる、データの誤用問題
- CRUDの単一データモデルより設計と実装が簡単になる。ただし、CRUDはスキャーフォルドメカニズムによって自動生成できない
- リードモデルはSQLビューもしくは即時プロジェクションを生成するか。
- 同じ物理ストアに格納する場合は、パフォーマンス、スケーラビリティ、セキュリティを最大化するため、データストアを物理的に分けるのが一般的
イベントソーシングパターン
- ステートソーシング(CRUD)の短所としてあげているもの
  - 更新時のロックがパフォーマンスと応答性を低下させる
  - 単一データ項目への更新は競合が起きやすい(コラボレータが複数の場合)
  - 監査メカニズムがない限り、履歴が失われる
- ESのメリット
  - イベントが不変であり、追記保存するだけ。イベントを処理するプロセスは非同期処理で問題が生じない
  - イベントは、データストアを更新しない、シンプルなオブジェクト。
  - イベントはドメインエキスパートの関心事。
  - 同時更新による競合の発生を防ぐことができる（ただし、ドメインオブジェクトが矛盾した状態にならないよう依然として保護が必要)

DDD,CQRS関連

マイクロサービスで DDD と CQRS パターンを使ってビジネスの複雑さに取り組む

マイクロサービス関連

マイクロサービス関連。DDDだと戦略的設計の部分。

マイクロサービスアーキテクチャの概要

Scala.js ウェブフレームワーク Facade 調査(2019年4月版)

2019-04-17T09:16:17+09:00

主要なウェブフレームワークのFacadeについて調査した(2019/4/17日時点)。

React.js

Reactバージョン	Scalaバージョン	ライブラリ名	スター数	最終更新日時	タグ形式	ReactRouterサポート	Reduxサポート	備考
16.6+	2.12,2.11	japgolly/scalajs-react	1196	1時間前	Scalatags形式	Scala.js独自実装	サポートなし
16.8.1	2.12	shadaj/slinky	276	4日前	case class	なし	なし	japgolly/scalajs-reactに依存, ReactNative対応
16.8.1+	2.12	aappddeevv/scalajs-reaction	17	25日前	case class	あり	あり
15.5.3	2.12	shogowada/scalajs-reactjs	23	2017/5	Scalatags形式	あり	あり
0.11.0	2.11	xored/scala-js-react	133	2015/2	scalax	なし	なし

Reactコンポーネント関連
- payalabs/scalajs-react-bridge
- chandu0101/scalajs-react-components

所感

aappddeevv/scalajs-reactionもreact-router,redux対応しているので魅力的だが、スターと更新頻度的にjapgolly/scalajs-reactが安心
japgolly/scalajs-reactのルーターは独自実装だが使えれば問題ない。Redux部分もScala.jsで関数型プログラミングすればなくても問題なさそう

Vue.js

Vueバージョン	Scalaバージョン	ライブラリ名	スター数	最終更新日時	Vue Routerサポート	Vuexサポート
2.x	2.11,2.12	random-scalor/scala-js-vue	3	2018/2	あり	あり
2.x	2.12	massung/scala-js-vue	12	2017/11	なし	なし
2.x	2.11	fancellu/scalajs-vue	76	2017/5	なし	なし

所感

とはいえどれも古くなってきている…。
まともに使えそうなものはrandom-scalor/scala-js-vue

Angular

最新のAngularを使えるFacadeを見つけることができなかった…。

まとめ

Scala.jsでウェブアプリケーションを作るならscalajs-react一択…。他は自分でがっつりコントリビュートする気がないと、いろいろ大変そうです。ということで、サンプルプロジェクトを二種類用意したので、興味があれば確認してみてください。

https://github.com/j5ik2o/scalajs-react-webpack4-example https://github.com/j5ik2o/scalajs-vuejs-webpack4-example

ID生成方法についてあれこれ

2019-03-21T15:01:23+09:00

引っ越しました。

ID生成方法についてあれこれ

akka-streamを使ってmemcachedクライアントを作るには

2018-12-10T18:36:18+09:00

かなり前になるのですが、akka-streamの習作課題として、Memcachedクライアントを実装したので、概要を解説する記事をまとめます。詳しくはgithubをみてください。

https://github.com/j5ik2o/reactive-memcached

TCPのハンドリング方法

akkaでTCPをハンドリングするには、以下の二つになる。おそらく

akka.actorとakka.ioのパッケージを使う方式。つまり、アクターでTCP I/Oを実装する方法。
akka.streamのTcp#outgoingConnectionというAPIを使う方法

今回は、akka-streamをベースにしたかったので、2を採用しました。

outgoingConnectionメソッドの戻り値の型は、Flow[ByteString, ByteString, Future[OutgoingConnection]]です。ByteStringを渡せば、ByteStringが返ってくるらしい。わかりやすいですね。そしてストリームが起動中であれば、コネクションは常時接続された状態になります。

def outgoingConnection(
  remoteAddress : InetSocketAddress,
  localAddress : Option[InetSocketAddress],
  options : Traversable[SocketOption], 
  halfClose : Boolean,
  connectTimeout : Duration,
  idleTimeout : Duration) : Flow[ByteString, ByteString, Future[Tcp.OutgoingConnection]]

Memcachedのコネクションを表現するオブジェクトを実装する

では、早速 Memcachedのコネクションを表現するオブジェクトである MemcachedConnection を実装します。このオブジェクトを生成するとTCP接続され、破棄されると切断されます。そして、考えたインターフェイスは以下です(別にtrait切り出さなくてもよかったですが、説明のために分けました)。sendメソッドにコマンドを指定して呼ぶとレスポンスが返る単純なものです。ちなみに、sendメソッドの戻り値の型はmonix.eval.Taskです。詳しくは https://monix.io/docs/3x/eval/task.html をご覧ください。

trait MemcachedConnection {
  def id: UUID // 接続ID
  def shutdown(): Unit // シャットダウン
  def peerConfig: Option[PeerConfig] // 接続先設定

  def send[C <: CommandRequest](cmd: C): Task[cmd.Response] // コマンドの送信

  // ...
}

実装はどうなるか。全貌は以下。先ほどのTcp#outgoingConnectionを使います。

private[memcached] class MemcachedConnectionImpl(_peerConfig: PeerConfig,
                                                 supervisionDecider: Option[Supervision.Decider])(
    implicit system: ActorSystem
) extends MemcachedConnection {

  // ...

  private implicit val mat: ActorMaterializer = ...

  protected val tcpFlow: Flow[ByteString, ByteString, NotUsed] =
    RestartFlow.withBackoff(minBackoff, maxBackoff, randomFactor, maxRestarts) { () =>
      Tcp()
        .outgoingConnection(remoteAddress, localAddress, options, halfClose, connectTimeout, idleTimeout)
    }

  protected val connectionFlow: Flow[RequestContext, ResponseContext, NotUsed] =
    Flow.fromGraph(GraphDSL.create() { implicit b =>
      import GraphDSL.Implicits._
      val requestFlow = b.add(
        Flow[RequestContext]
          .map { rc =>
            log.debug(s"request = [{}]", rc.commandRequestString)
            (ByteString.fromString(rc.commandRequest.asString + "\r\n"), rc)
          }
      )
      val responseFlow = b.add(Flow[(ByteString, RequestContext)].map {
        case (byteString, requestContext) =>
          log.debug(s"response = [{}]", byteString.utf8String)
          ResponseContext(byteString, requestContext)
      })
      val unzip = b.add(Unzip[ByteString, RequestContext]())
      val zip   = b.add(Zip[ByteString, RequestContext]())
      requestFlow.out ~> unzip.in
      unzip.out0 ~> tcpFlow ~> zip.in0
      unzip.out1 ~> zip.in1
      zip.out ~> responseFlow.in
      FlowShape(requestFlow.in, responseFlow.out)
    })

  protected val (requestQueue: SourceQueueWithComplete[RequestContext], killSwitch: UniqueKillSwitch) = Source
    .queue[RequestContext](requestBufferSize, overflowStrategy)
    .via(connectionFlow)
    .map { responseContext =>
      log.debug(s"req_id = {}, command = {}: parse",
                responseContext.commandRequestId,
                responseContext.commandRequestString)
      val result = responseContext.parseResponse // レスポンスのパース
      responseContext.completePromise(result.toTry) // パース結果を返す
    }
    .viaMat(KillSwitches.single)(Keep.both)
    .toMat(Sink.ignore)(Keep.left)
    .run()

  override def shutdown(): Unit = killSwitch.shutdown()

  override def send[C <: CommandRequest](cmd: C): Task[cmd.Response] = Task.deferFutureAction { implicit ec =>
    val promise = Promise[CommandResponse]()
    requestQueue
      .offer(RequestContext(cmd, promise, ZonedDateTime.now()))
      .flatMap {
        case QueueOfferResult.Enqueued =>
          promise.future.map(_.asInstanceOf[cmd.Response])
        case QueueOfferResult.Failure(t) =>
          Future.failed(BufferOfferException("Failed to send request", Some(t)))
        case QueueOfferResult.Dropped =>
          Future.failed(
            BufferOfferException(
              s"Failed to send request, the queue buffer was full."
            )
          )
        case QueueOfferResult.QueueClosed =>
          Future.failed(BufferOfferException("Failed to send request, the queue was closed"))
      }
  }

}

TCPの送受信するにはtcpFlowメソッドが返すFlowに必要なByteStringを流して、ByteStringを受け取ればいいですが、リクエストとレスポンスを扱うためにもう少し工夫が必要です。そのためにconnectionFlowメソッドはtcpFlowメソッドを内部Flowとして利用します。そして、FlowはRequestContextとResponseContextの型を利用します。その実装は以下のようなシンプルなものです。キューであるrequestQueueはconnectionFlowにリクエストを送信します。ストリームの後半で返ってきたレスポンスを処理するという流れになっています。キューへのリクエストのエンキューはsendメソッドが行います。sendメソッドが呼ばれるとRequestContextを作ってrequestQueueにエンキュー、完了するとレスポンスを返します。requestQueueはストリームと繋がっていて、エンキューされたRequestContextはconnectionFlowに渡され返ってきたResponseContextがレスポンス内容をパースし、その結果をPromise経由で返すというものです¹。エラーハンドリングについて、エラーを起こしやすいところにRestartFlow.withBackoffを入れています。

final case class RequestContext(commandRequest: CommandRequest,
                                promise: Promise[CommandResponse],
                                requestAt: ZonedDateTime) {
  val id: UUID                     = commandRequest.id
  val commandRequestString: String = commandRequest.asString
}

final case class ResponseContext(byteString: ByteString,
                                 requestContext: RequestContext,
                                 requestsInTx: Seq[CommandRequest] = Seq.empty,
                                 responseAt: ZonedDateTime = ZonedDateTime.now)
    extends ResponseBase {

  val commandRequest: CommandRequest = requestContext.commandRequest

  def withRequestsInTx(values: Seq[CommandRequest]): ResponseContext = copy(requestsInTx = values)
  // レスポンスのパース
  def parseResponse: Either[ParseException, CommandResponse] = {
    requestContext.commandRequest match {
      case scr: CommandRequest =>
        scr.parse(ByteVector(byteString.toByteBuffer)).map(_._1)
    }
  }

}

コネクションオブジェクトの使い方は簡単です。ほとんどの場合は、このようにコネクションオブジェクトを直接操作せずに、高レベルなAPIを操作したいと思うはずです。そのためのクライアントオブジェクトはあとで述べます。

val connection = MemcachedConnection(
  PeerConfig(new InetSocketAddress("127.0.0.1", memcachedTestServer.getPort),
  backoffConfig = BackoffConfig(maxRestarts = 1)),
  None
)

val resultFuture = (for {
  _   <- connection.send(SetRequest(UUID.randomUUID(), "key1", "1", 10 seconds))
  _   <- connection.send(SetRequest(UUID.randomUUID(), "key2", "2", 10 seconds))
  gr1 <- connection.send(GetRequest(UUID.randomUUID(), "key1"))
  gr2 <- connection.send(GetRequest(UUID.randomUUID(), "key2"))
} yield (gr1, gr2)).runAsync
val result = Await.result(resultFuture, Duration.Inf) // (1, 2)

コマンドの実装

コマンドの一例はこんな感じです。 asStringメソッドは文字通りMemcachedにコマンドを送信するときに利用される文字列です。responseParserはfastparseで実装されたレスポンスパーサを指定します。parseResponseメソッドはMemcachedからのレスポンスを表現する構文木をコマンドのレンスポンスに変換するための関数です。これは少し複雑なのであとで説明します。

final class GetRequest private (val id: UUID, val key: String) extends CommandRequest with StringParsersSupport {

  override type Response = GetResponse
  override val isMasterOnly: Boolean = false

  override def asString: String = s"get $key"

  // レスポンスを解析するためのパーサを指定。レスポンス仕様に合わせて指定する
  override protected def responseParser: P[Expr] = P(retrievalCommandResponse)

  // ASTをコマンドレスポンスに変換する
  override protected def parseResponse: Handler = {
    case (EndExpr, next) =>
      (GetSucceeded(UUID.randomUUID(), id, None), next)
    case (ValueExpr(key, flags, length, casUnique, value), next) =>
      (GetSucceeded(UUID.randomUUID(), id, Some(ValueDesc(key, flags, length, casUnique, value))), next)
    case (ErrorExpr, next) =>
      (GetFailed(UUID.randomUUID(), id, MemcachedIOException(ErrorType.OtherType, None)), next)
    case (ClientErrorExpr(msg), next) =>
      (GetFailed(UUID.randomUUID(), id, MemcachedIOException(ErrorType.ClientType, Some(msg))), next)
    case (ServerErrorExpr(msg), next) =>
      (GetFailed(UUID.randomUUID(), id, MemcachedIOException(ErrorType.ServerType, Some(msg))), next)
  }

}

これはGetRequestの上位traitであるCommandRequestです。Memcachedのコマンド送信に必要なのはasStringメソッドだけで、コマンドのレスポンスのパースにはparseメソッドが利用されます。

trait CommandRequest {
  type Elem
  type Repr
  type P[+T] = core.Parser[T, Elem, Repr]

  type Response <: CommandResponse

  type Handler = PartialFunction[(Expr, Int), (Response, Int)]

  val id: UUID
  val key: String
  val isMasterOnly: Boolean

  def asString: String

  protected def responseParser: P[Expr]

  protected def convertToParseSource(s: ByteVector): Repr

  def parse(text: ByteVector, index: Int = 0): Either[ParseException, (Response, Int)] = {
    responseParser.parse(convertToParseSource(text), index) match {
      case f @ Parsed.Failure(_, index, _) =>
        Left(new ParseException(f.msg, index))
      case Parsed.Success(value, index) => Right(parseResponse((value, index)))
    }
  }

  protected def parseResponse: Handler

}

レスポンス・パーサの実装

レスポンスパーサは、Memcachedの仕様に合わせて以下の定義から適切なものを選んで利用します。詳しくは公式ドキュメントをみてください。標準のパーサーコンビネータと少し違うところがありますが、概ね似たような感じで書けます。Memcachedのレスポンスのルールは単純で左再帰除去などもしなくていいので、パーサーコンビネータのはじめての題材にはよいと思います。

object StringParsers {

  val digit: P0      = P(CharIn('0' to '9'))
  val lowerAlpha: P0 = P(CharIn('a' to 'z'))
  val upperAlpha: P0 = P(CharIn('A' to 'Z'))
  val alpha: P0      = P(lowerAlpha | upperAlpha)
  val alphaDigit: P0 = P(alpha | digit)
  val crlf: P0       = P("\r\n")

  val error: P[ErrorExpr.type]        = P("ERROR" ~ crlf).map(_ => ErrorExpr)
  val clientError: P[ClientErrorExpr] = P("CLIENT_ERROR" ~ (!crlf ~/ AnyChar).rep(1).! ~ crlf).map(ClientErrorExpr)
  val serverError: P[ServerErrorExpr] = P("SERVER_ERROR" ~ (!crlf ~/ AnyChar).rep(1).! ~ crlf).map(ServerErrorExpr)
  val allErrors: P[Expr]              = P(error | clientError | serverError)

  val end: P[EndExpr.type]             = P("END" ~ crlf).map(_ => EndExpr)
  val deleted: P[DeletedExpr.type]     = P("DELETED" ~ crlf).map(_ => DeletedExpr)
  val stored: P[StoredExpr.type]       = P("STORED" ~ crlf).map(_ => StoredExpr)
  val notStored: P[NotStoredExpr.type] = P("NOT_STORED" ~ crlf).map(_ => NotStoredExpr)
  val exists: P[ExistsExpr.type]       = P("EXISTS" ~ crlf).map(_ => ExistsExpr)
  val notFound: P[NotFoundExpr.type]   = P("NOT_FOUND" ~ crlf).map(_ => NotFoundExpr)
  val touched: P[TouchedExpr.type]     = P("TOUCHED" ~ crlf).map(_ => TouchedExpr)

  val key: P[String]     = (!" " ~/ AnyChar).rep(1).!
  val flags: P[Int]      = digit.rep(1).!.map(_.toInt)
  val bytes: P[Long]     = digit.rep(1).!.map(_.toLong)
  val casUnique: P[Long] = digit.rep(1).!.map(_.toLong)

  val incOrDecCommandResponse: P[Expr] = P(notFound | ((!crlf ~/ AnyChar).rep.! ~ crlf).map(StringExpr) | allErrors)
  val storageCommandResponse: P[Expr]  = P((stored | notStored | exists | notFound) | allErrors)

  val value: P[ValueExpr] =
    P("VALUE" ~ " " ~ key ~ " " ~ flags ~ " " ~ bytes ~ (" " ~ casUnique).? ~ crlf ~ (!crlf ~/ AnyChar).rep.! ~ crlf)
      .map {
        case (key, flags, bytes, cas, value) =>
          ValueExpr(key, flags, bytes, cas, value)
      }

  val version: P[VersionExpr] = P("VERSION" ~ " " ~ alphaDigit.rep(1).!).map(VersionExpr)

  val retrievalCommandResponse: P[Expr] = P(end | value | allErrors)

  val deletionCommandResponse: P[Expr] = P(deleted | notFound | allErrors)

  val touchCommandResponse: P[Expr] = P(touched | notFound | allErrors)

  val versionCommandResponse: P[Expr] = P(version | allErrors)
}

クライアントの実装

次はクライアント実装。MemcachedClient#sendメソッドはコマンドを受け取り、ReaderTTaskMemcachedConnection[cmd.Response]を返します。ReaderTTaskMemcachedConnectionはMemcachedのために特化したReaderTで、コネクションを受け取り、レスポンスを返すTaskを返します。Memcachedのための高レベルなAPIはこのsendメソッドを利用して実装されます。get,setなどのメソッドの内部でコマンドを作成し、レスポンスを戻り値にマッピングするだけで、使いやすい高レベルAPIになります。また、ReaderTを返すためfor式での簡潔な記述もできます。

package object memcached {

  type ReaderTTask[C, A]                  = ReaderT[Task, C, A]
  type ReaderTTaskMemcachedConnection[A]  = ReaderTTask[MemcachedConnection, A]
  type ReaderMemcachedConnection[M[_], A] = ReaderT[M, MemcachedConnection, A]

}

final class MemcachedClient()(implicit system: ActorSystem) {

  def send[C <: CommandRequest](cmd: C): ReaderTTaskMemcachedConnection[cmd.Response] = ReaderT(_.send(cmd))

  def get(key: String): ReaderTTaskMemcachedConnection[Option[ValueDesc]] =
    send(GetRequest(UUID.randomUUID(), key)).flatMap {
      case GetSucceeded(_, _, result) => ReaderTTask.pure(result)
      case GetFailed(_, _, ex)        => ReaderTTask.raiseError(ex)
    }

  def set[A: Show](key: String,
                   value: A,
                   expireDuration: Duration = Duration.Inf,
                   flags: Int = 0): ReaderTTaskMemcachedConnection[Int] =
    send(SetRequest(UUID.randomUUID(), key, value, expireDuration, flags)).flatMap {
      case SetExisted(_, _)    => ReaderTTask.pure(0)
      case SetNotFounded(_, _) => ReaderTTask.pure(0)
      case SetNotStored(_, _)  => ReaderTTask.pure(0)
      case SetSucceeded(_, _)  => ReaderTTask.pure(1)
      case SetFailed(_, _, ex) => ReaderTTask.raiseError(ex)
    }

   // ...

}

for式での利用例

val client = new MemcachedClient()
val resultFuture = (for {
  _  <- client.set(key, "1")
  r1 <- client.get(key)
  _  <- client.set(key, "2")
  r2 <- client.get(key)
} yield (r1, r2)).run(connection).runAsync
val result = Await.result(resultFuture, Duration.Inf) // (1, 2)

コネクションプール

コネクションとクライアントを実装できたら、次はコネクションプールも欲しくなります。MemcachedConnectionをプーリングして選択できればいいわけなので、commons-poolなど使えば楽ですね。コネクションをプールするアルゴリズム(HashRingなど)も複数考えられるので、工夫するとなかなか面白いです。

implicit val system = ActorSystem()

val peerConfig = PeerConfig(remoteAddress = new InetSocketAddress("127.0.0.1", 6379))
val pool = MemcachedConnectionPool.ofSingleRoundRobin(sizePerPeer = 5, peerConfig, RedisConnection(_)) // powered by RoundRobinPool
val connection = MemcachedConnection(connectionConfig)
val client = MemcachedClient()

// ローンパターン形式
val resultFuture1 = pool.withConnectionF{ con =>
  (for{
    _ <- client.set("foo", "bar")
    r <- client.get("foo")
  } yield r).run(con) 
}.runAsync

// モナド形式
val resultFuture2 = (for {
  _ <- ConnectionAutoClose(pool)(client.set("foo", "bar").run)
  r <- ConnectionAutoClose(pool)(client.get("foo").run)
} yield r).run().runAsync

まとめ

というわけでこんな風にakka-streamを使えばTCPクライアントも比較的簡単に実装できると思います。参考にしてみてください。

バックプレッシャを適切にハンドリングするには、ストリームを常に起動した状態にしておく必要があります、要求ごとにストリームを起動していると効果的ではありません))↩

「エンティティの同一性を表現するためにequalsをオーバーライドすべきか否か」の感想

2018-12-05T13:08:46+09:00

毎日、ドメイン駆動設計というか、設計の話が投稿されると、楽しくなりますね。

さて、今日の話題は、以下です！

エンティティの同一性を表現するためにequalsをオーバーライドすべきか否か

”稀によくあるサンプル”。多分これ僕が書いた事例ですね。ということで、なぜそうしたか、理由など書いておきたいと思います。

なぜこうしたか

equalsの責務は以下のとおりで、オブジェクトが等しいかどうかを示すものです。エンティティの等価判定の基準に、識別子以外の属性は含めていません。 これにはトレードオフがあります。

https://docs.oracle.com/javase/jp/8/docs/api/java/lang/Object.html Object#equalsの責務は、「このオブジェクトと他のオブジェクトが等しいかどうかを示します。」

以下のように実装したと場合に、(ID以外の)属性が変わったエンティティを特定することが可能です。

scala> case class EmployeeId(value: Int) extends Identifier
defined class EmployeeId

scala> case class Employee(identifier: EmployeeId, name: String) extends Entity[EmployeeId]
defined class Employee

scala> val list = Seq(Employee(EmployeeId(1), "yamada taro"), Employee(EmployeeId(2), "yamada hanako"))
list: Seq[Employee] = List(Employee(EmployeeId(1),yamada taro), Employee(EmployeeId(2),yamada hanako))

// "yamada hanako"が結婚して名前が変わるイベントが発生、リストの内容も合わせて変更される

scala> list.contains(Employee(EmployeeId(2), "yamada hanako"))
res0: Boolean = true

Entity#sameIdentityAsの場合は、　コレクションのメソッドに組み込むことはできないのでそれなりに実装を工夫する必要がありますね。

論理的等価性検査としてのequals

上記のメリットはよいとして、一体equalsメソッドとして何を求めるているのか。DDDの観点があろうがなかろうか、equalsの契約を逸脱する設計をしないようにすべきと考えます。久しぶりに、Effective Javaを開いてみると、equalsは「論理的等価性」検査の責務を持つというような記述はあるものの、「論理的等価性」が具体的に何かは明記されていませんでした。

ちなみにjava.lang.Objectのデフォルト実装は以下となっています。多くの場合はサブクラスで固有のequalsメソッドとしてオーバーライドされますが、されない場合もあります。java.util.Randomは、同じ乱数列を生成するかで等価判定できたはずですが、クライアントがそれを求めてなかったので、デフォルト実装のままとなっているようです。

public boolean equals(Object obj) {
  return (this == obj);
}

契約プログラミングの観点から

契約プログラミングの観点では、java.lan.Object#equalsのJavadocに書かれていること以上のことは求めてはいけません。つまり、一般契約に従っている以上は「オブジェクトが等しいかどうか」の仕様を満たしているはずです。

DDDの文脈では、等価性は（エンティティが持つ）値がすべて同じであればtrueとみなし、同一性は識別子が同じであればtrueとみなすものと解釈できそうです。つまり、エンティティの定義である「同一性によって定義されるオブジェクト」に照らすと equals をオーバーライドすることは適切ではありません。この点では、本来オーバーライドすべきは eq と言えるかもしれません。

このアイデアは有益ですしこの設計を取ってもよいと思っていますが、java.lan.Object#equalsの契約に照らして考えるに「適切ではありません」とまでは言い切れないと考えています。

結局どうすべきか

まぁ身の蓋もないですが、こうすべきだと思っています。(ここでオーバーライドするという意味は、IDのみの等価判断する実装としてオーバーライドするかしないかという意味です)

まぁ、オーバーライドするかしないかは、トレードオフがあるので、プロジェクトやチームで判断してくださいというスタンスかな、僕は。
— かとじゅん (@j5ik2o) 2018年12月5日

また、equalsやhashCodeのようにもともと抽象度の高いインターフェイスは意図がわかりにくいことがあります。対策としては、ドキュメンテーションコメントに自然言語できちんと設計の意図を記述するべきで、利用者も求められる契約が何かを理解すべきだと思っています。（自壊の念を込めて）

実装を追わなければ equals がオーバーライドされていることが分からないことは、余分な意識コストとなってしまうでしょう。

DbCの観点でいえば、equals, hashCodeはDDDでいう意図の明白なインターフェイスではありませんね。コードだけでは設計の意図がわからない場合は、javadocなりscaladocに自然言語で仕様を記述すべきですね。
— かとじゅん (@j5ik2o) 2018年12月5日

akka-httpにswagger2.xを組み込む方法

2018-10-01T09:05:25+09:00

akka-httpにswagger2.xを組み込む方法を以下に示します。

※DIコンテナであるAirframeを使っていますが、もちろん必須ではありません。適宜読み替えてくだだい。

ライブラリの依存関係

swagger-akka-httpを追加します。javax.ws.rs-apiはアノテーションを利用するために追加します。akka-http-corsは必要に応じて追加してください。

libraryDependencies ++= Seq(
"com.typesafe.akka"            %% "akka-http"         % "10.1.5",
"com.github.swagger-akka-http" %% "swagger-akka-http" % "2.0.0"
"javax.ws.rs"                  % "javax.ws.rs-api"    % "2.0.1"
"ch.megard"                    %% "akka-http-cors"    % "0.3.0"
// ...
)

コントローラの例

コントローラに相当するクラスにアクションを作って、そのメソッドにアノテーションを割り当てます。別にコントローラを定義しなくとも、エンドポイントごとにRoute定義が分かれていて、アノテーションが付与できればよいです。

アノテーションの使い方は、Swagger 2.X Annotationsを読んでください。

package spetstore.interface.api.controller

import java.time.ZonedDateTime

import akka.http.scaladsl.server.{Directives, Route}
import de.heikoseeberger.akkahttpcirce.FailFastCirceSupport._
import io.circe.generic.auto._
import io.swagger.v3.oas.annotations.Operation
import io.swagger.v3.oas.annotations.media.{Content, Schema}
import io.swagger.v3.oas.annotations.parameters.RequestBody
import io.swagger.v3.oas.annotations.responses.ApiResponse
import javax.ws.rs._
import monix.eval.Task
import monix.execution.Scheduler
import org.hashids.Hashids
import org.sisioh.baseunits.scala.money.Money
import spetstore.domain.model.basic.StatusType
import spetstore.domain.model.item._
import spetstore.interface.api.model.{CreateItemRequest, CreateItemResponse, CreateItemResponseBody}
import spetstore.interface.generator.jdbc.ItemIdGeneratorOnJDBC
import spetstore.interface.repository.ItemRepository
import wvlet.airframe._

import scala.concurrent.Future

@Path("/items")
@Consumes(Array("application/json"))
@Produces(Array("application/json"))
trait ItemController extends Directives {

  private val itemRepository: ItemRepository[Task]         = bind[ItemRepository[Task]]

  private val itemIdGeneratorOnJDBC: ItemIdGeneratorOnJDBC = bind[ItemIdGeneratorOnJDBC]

  private val hashids = bind[Hashids]

  def route: Route = create

  private def convertToAggregate(id: ItemId, request: CreateItemRequest): Item = Item(
    id = id,
    status = StatusType.Active,
    name = ItemName(request.name),
    description = request.description.map(ItemDescription),
    categories = Categories(request.categories),
    price = Price(Money.yens(request.price)),
    createdAt = ZonedDateTime.now(),
    updatedAt = None
  )

  @POST
  @Operation(
    summary = "Create item",
    description = "Create Item",
    requestBody =
      new RequestBody(content = Array(new Content(schema = new Schema(implementation = classOf[CreateItemRequest])))),
    responses = Array(
      new ApiResponse(responseCode = "200",
                      description = "Create response",
                      content = Array(new Content(schema = new Schema(implementation = classOf[CreateItemResponse])))),
      new ApiResponse(responseCode = "500", description = "Internal server error")
    )
  )
  def create: Route = path("items") {
    post {
      extractActorSystem { implicit system =>
        implicit val scheduler: Scheduler = Scheduler(system.dispatcher)
        entity(as[CreateItemRequest]) { request =>
          val future: Future[CreateItemResponse] = (for {
            itemId <- itemIdGeneratorOnJDBC.generateId()
            _      <- itemRepository.store(convertToAggregate(itemId, request))
          } yield CreateItemResponse(Right(CreateItemResponseBody(hashids.encode(itemId.value))))).runAsync
          onSuccess(future) { result =>
            complete(result)
          }
        }
      }
    }
  }

  // ...

}

swagger-ui

swagger-uiのdistをsrc/main/resource/swaggerとしてコピーしてください。

SwaggerHttpService

次にSwaggerHttpServiceの実装を用意します。

package spetstore.interface.api

import com.github.swagger.akka.SwaggerHttpService
import com.github.swagger.akka.model.Info

class SwaggerDocService(hostName: String, port: Int, val apiClasses: Set[Class[_]]) extends SwaggerHttpService {
  override val host                = s"127.0.0.1:$port" //the url of your api, not swagger's json endpoint
  override val apiDocsPath         = "api-docs" //where you want the swagger-json endpoint exposed
  override val info                = Info() //provides license and other description details
  override val unwantedDefinitions = Seq("Function1", "Function1RequestContextFutureRouteResult")
}

routeの設定

akka-httpのRouteは以下を参考にしてください。SwaggerDocServiceとコントローラをrouteに加えます。また、CORSが必要なら、"ch.megard" %% "akka-http-cors" % "0.3.0" を使うとよいと思います。

package spetstore.interface.api

import akka.http.scaladsl.model.{ ContentTypes, HttpEntity, HttpResponse }
import akka.http.scaladsl.server.{ Directives, Route, StandardRoute }
import wvlet.airframe._
import ch.megard.akka.http.cors.scaladsl.CorsDirectives._
import spetstore.interface.api.controller.ItemController

trait Routes extends Directives {

  private lazy val itemController    = bind[ItemController]
  private lazy val swaggerDocService = bind[SwaggerDocService]

  private def index(): StandardRoute = complete(
    HttpResponse(
      entity = HttpEntity(
        ContentTypes.`text/plain(UTF-8)`,
        "Wellcome to API"
      )
    )
  )

  def routes: Route = cors() {
    pathEndOrSingleSlash {
      index()
    } ~ path("swagger") {
      getFromResource("swagger/index.html")
    } ~ getFromResourceDirectory("swagger") ~
    swaggerDocService.routes ~ itemController.route
  }

}

ブートストラップ

akka-httpの起動部分のコードです。

package spetstore.interface.api

import akka.actor.ActorSystem
import akka.http.scaladsl.Http
import akka.http.scaladsl.Http.ServerBinding
import akka.http.scaladsl.settings.ServerSettings
import akka.stream.ActorMaterializer
import wvlet.airframe._

import scala.concurrent.Future
import scala.util.{ Failure, Success }

trait ApiServer {

  implicit val system           = bind[ActorSystem]
  implicit val materializer     = ActorMaterializer()
  implicit val executionContext = system.dispatcher

  private val routes = bind[Routes].routes

  def start(host: String, port: Int, settings: ServerSettings): Future[ServerBinding] = {
    val bindingFuture = Http().bindAndHandle(handler = routes, interface = host, port = port, settings = settings)
    bindingFuture.onComplete {
      case Success(binding) =>
        system.log.info(s"Server online at http://${binding.localAddress.getHostName}:${binding.localAddress.getPort}/")
      case Failure(ex) =>
        system.log.error(ex, "occurred error")
    }
    sys.addShutdownHook {
      bindingFuture
        .flatMap(_.unbind())
        .onComplete { _ =>
          materializer.shutdown()
          system.terminate()
        }
    }
    bindingFuture
  }

}

アプリケーションのブートストラップ部分です。

package spetstore.api

import akka.actor.ActorSystem
import akka.http.scaladsl.settings.ServerSettings
import monix.eval.Task
import org.hashids.Hashids
import slick.basic.DatabaseConfig
import slick.jdbc.JdbcProfile
import spetstore.domain.model.item.ItemId
import spetstore.interface.api.controller.ItemController
import spetstore.interface.api.{ApiServer, Routes, SwaggerDocService}
import spetstore.interface.generator.IdGenerator
import spetstore.interface.generator.jdbc.ItemIdGeneratorOnJDBC
import spetstore.interface.repository.{ItemRepository, ItemRepositoryBySlick}
import wvlet.airframe._

/**
  * http://127.0.0.1:8080/swagger
  */
object Main {

  def main(args: Array[String]): Unit = {
    val parser = new scopt.OptionParser[AppConfig]("spetstore") {
      opt[String]('h', "host").action((x, c) => c.copy(host = x)).text("host")
      opt[Int]('p', "port").action((x, c) => c.copy(port = x)).text("port")
    }
    val system = ActorSystem("spetstore")
    val dbConfig: DatabaseConfig[JdbcProfile] =
      DatabaseConfig.forConfig[JdbcProfile](path = "spetstore.interface.storage.jdbc", system.settings.config)

    parser.parse(args, AppConfig()) match {
      case Some(config) =>
        val design = newDesign
          .bind[Hashids].toInstance(new Hashids(system.settings.config.getString("spetstore.interface.hashids.salt")))
          .bind[ActorSystem].toInstance(system)
          .bind[JdbcProfile].toInstance(dbConfig.profile)
          .bind[JdbcProfile#Backend#Database].toInstance(dbConfig.db)
          .bind[Routes].toSingleton
          .bind[SwaggerDocService].toInstance(
          new SwaggerDocService(config.host, config.port, Set(classOf[ItemController]))
        )
          .bind[ApiServer].toSingleton
          .bind[ItemRepository[Task]].to[ItemRepositoryBySlick]
          .bind[IdGenerator[ItemId]].to[ItemIdGeneratorOnJDBC]
          .bind[ItemController].toSingleton
        design.withSession { session =>
          val system = session.build[ActorSystem]
          session.build[ApiServer].start(config.host, config.port, settings = ServerSettings(system))
        }
      case None =>
        println(parser.usage)
    }
  }
}

まとめ

最低限、考慮すべきこととしては、akka-httpのroute dslはエンドポイントごとに分割してswaggerアノテーションを割り当てれるようにしてください。これ以外はswaggerの一般的な使い方と変わりません。

Getter/Setterを避けて役に立つドメインオブジェクトを作る

2018-08-14T13:41:25+09:00

Clean Architecture 達人に学ぶソフトウェアの構造と設計を読んでます。モデリングに関しては成分薄めですが、よい本だと思います。はい。

Clean Architecture 達人に学ぶソフトウェアの構造と設計

作者: Robert C.Martin,角征典,高木正弘
出版社/メーカー: KADOKAWA
発売日: 2018/07/27
メディア: 単行本
この商品を含むブログを見る

本書の大筋から少し逸れるが、「5章オブジェクト指向プログラミング」の「カプセル化」が面白かったので、これを切り口にモデリングについて考えてみる。

OO言語のカプセル化はすでに弱体化している

オブジェクト指向の三大要素の一つである、カプセル化について、以下のようなことが書いてあります。

「カプセル化」がOOの定義の一部となっているのは、OO言語がデータと関数のカプセル化を簡単かつ効果的なものにしているからだ。それによって、データと関数の周囲に線を引くことができる。その線の外側にはデータが見えないようになっていて、一部の関数だけが見えるようになっている。

本書に登場するある座標を表すオブジェクトをJavaでいつも通り書いてみた。フィールドはプライベートで、直接アクセスできないようにGetterもあるし、距離を計算するメソッドもある。カプセル化の例としてわかりやすいものだが、本章ではカプセル化に問題があると言及している。日常的にこういうコードを書いている人にとって、これの何が悪いのか全くわからない…。僕もそのひとりだった。

public class Point {

  public Point(double x, double y) { this.x = x; this.y = y; }
  // 距離を測る
  public double distance(Point p) {
    double dx = x - p.x;
    double dy = y - p.y;
    return Math.sqrt(dx * dx + dy * dy);
  }

  public double getX() { return x; }
  public double getY() { return y; }

  private double x;
  private double y;
}

早速、本書で紹介されている例を写経してみたので、みてみよう。C言語でPointオブジェクトを実装すると以下のようになると紹介されている。

まずpoint.hだ。久しぶりにC言語で書いた…。

#ifndef OOP_POINT_H
#define OOP_POINT_H

struct Point;
typedef struct Point* PPoint;

PPoint makePoint(double x, double y);
double distance(PPoint p1, PPoint p2);

#endif //OOP_POINT_H

次はpoint.cだ。構造体の宣言が.cファイルに書ける。

#include "point.h"
#include <stdlib.h>
#include <math.h>

struct Point {
    double x,y;
};

PPoint makePoint(double x, double y) {
    PPoint p = malloc(sizeof(struct Point));
    p->x = x;
    p->y = y;
    return p;
}

double distance(PPoint p1, PPoint p2) {
    double dx = p1->x - p2->x;
    double dy = p1->y - p2->y;
    return sqrt(dx*dx + dy*dy);
}

このようにPoint構造体をインスタンスと見立てて、内部状態をカプセル化しそれらを利用する関数群というのはよく見られる設計です。本章の解説は以下のとおり。

point.hのユーザは、struct Pointのメンバーにアクセスできない。makePoint()とdistance()は呼び出せるが、Pointのデータ構造や関数の実装については何も知らない。これは(非OO言語による)完ぺきなカプセル化である。

ヘッダにはPoint構造体の名前しかないので、ヘッダ利用者からはこの構造体の内部へアクセスができない。というか、ヘッダ利用者は 構造体の内部構造さえ知ることができない 。これが、 完璧なカプセル化 だと言及されている。

そういえば、C言語でライブラリを開発していた頃はこういうコードをよく書いていて、メンバーは存在自体を隠蔽していた記憶がある。

そして、著者はC++では、そういう完璧さが失われてしまったとしている。

だがその後、C++というOO言語が登場し、C言語の完璧なカプセル化が破られてしまった。C++のコンパイラの技術的な理由から、クラスのメンバー変数をヘッダファイルに宣言する必要があった。

C++では以下のようなコードになる。Cの例と比べると、 メンバ変数x, yがヘッダ利用者から見えてる 。もちろん、アクセス修飾子を使えば、コンパイラによる防御は可能だが、 ヘッダ利用者に内部に隠蔽すべき知識が、(ソースコードレベルでは)外部に暴露していることになる 。本章では、これを「カプセル化が壊れている」の根拠としている。

こういう視点からみると、C++だけではなく、Java, C#などヘッダと実装を分離しない言語ではカプセル化は弱体化していることになる*1。

#ifndef OOP_POINT_HPP
#define OOP_POINT_HPP

class Point {
public:
    Point(double x, double y);
    double distance(const Point& p) const;
private:
    double x;
    double y;
};

#endif //OOP_POINT_HPP

#include "point.hpp"
#include <math.h>

Point::Point(double x, double y) : x(x), y(y) {
}

double Point::distance(const Point &p) const {
    double dx = x - p.x;
    double dy = y - p.y;
    return sqrt(dx * dx + dy * dy)
}

追記：C++でもPimplイディオムを使えば完ぺきなカプセル化ができるようです。コメントいただき、ありがとうございました。

flat-leon.hatenablog.com

カプセル化を破るGetter/Setter

いまや完ぺきなカプセル化ができなくなってしまったが、今の問題は残念ながらそこじゃない。C++の例のようにprivate フィールドのままならよいが、安易にGetter, Setterを追加すると、知識のカプセル化が破られる。この問題はあまりに日常的に起こっていて気づきにくい*2。そして、そのGetter, Setterによって、ドメインオブジェクトが骨抜きになることはよくある。いわゆる貧血症オブジェクトを生み出してしまう問題だ。

たとえば、先ほど示したJavaのPointクラスのgetX(), getY()のGetterはカプセル化を弱めてしまっている。

public class Point {

  public Point(double x, double y) { this.x = x; this.y = y; }

  public double distance(Point p) {
    double dx = x - p.x;
    double dy = y - p.y;
    return Math.sqrt(dx * dx + dy * dy);
  }

  public double getX() { return x; }
  public double getY() { return y; }

  private double x;
  private double y;

}

そして、以下のようにPointクラスが担うべき距離計算処理は、getX(), getY()などのGetterによってカプセル化が壊れているので、Pointクラスの責務に逆らって他のクラスに実装できてしまう。

public class Point {
  public Point(double x, double y) { this.x = x; this.y = y; }
// カプセル化が弱いと、このメソッドがあってなくてもPointの責務を無視できる
//  public double distance(Point p) 
  public double getX() { return x; }
  public double getY() { return y; }
  private double x;
  private double y;
}

public class PointLogic {

   public double distance(Point p1, Point p2) {
    double dx = p1.getX() - p2.getX();
    double dy = p1.getY() - p2.getY();
    return Math.sqrt(dx * dx + dy * dy);
  }

}

Getter, Setter禁止とTell, Don't Ask原則

前述のような状況を改善させるには、「ThoughtWorksアンソロジー ―アジャイルとオブジェクト指向によるソフトウェアイノベーション」の「オブジェクト指向エクササイズ」には、「ルール9：Getter,Setter、プロパティを使用しないこと」という一見過激なルールが効果的だ。だいたい、初見で学ぶとやりすぎじゃねーの？と思うやつです。でも、やってみると意外と効果がある。

ThoughtWorksアンソロジー ―アジャイルとオブジェクト指向によるソフトウェアイノベーション

作者: ThoughtWorks Inc.,株式会社オージス総研オブジェクトの広場編集部
出版社/メーカー: オライリージャパン
発売日: 2008/12/27
メディア: 単行本（ソフトカバー）
購入: 14人クリック: 323回
この商品を含むブログ (81件) を見る

このルール9にはこんなことが書いてある。

インスタンス変数の適切な集合をカプセル化してもまだ設計がぎこちないときは、もっと直接的なカプセル化の違反がないかチェックしましょう。振る舞いがその場で簡単に値を求められるようになっていると、その振る舞いはインスタンス変数の後を付いてきません。(中略) これは後に、重複の大幅な削減や、新機能を実現するための修正の局所化、といった大きな効果をもたらします。このルールは「求めるな、命じよ」として一般的に言われています。

このルールを知らなくても、「求めるな、命じよ」(Tell, Don't Ask)という言葉を知ってる人は多いでしょう。

このGetter, Setterの不要・必要論はかなり昔からあって、以下のQiita記事がわかりやすいので読むとよいです。

qiita.com

記事中で、「求めるな、命じよ」(Tell, Don't Ask)というオブジェクト指向の原則がわかりやすく解説されている。

ある処理をする際、その処理に必要な情報をオブジェクトから引き出さないで、情報を持ったオブジェクトにその処理をさせろということ

Point#getX(), #getY()は、まさに情報を引き出す行為だ。Point#getX(), #getY()を使って構成されるロジックは、Pointが持つべきロジックかもしれない。

あるクラスで他クラスのgetterを呼び出すような処理を実装している場合、その処理は本来呼び出されるクラス側で実装されるべきだということ

せっかくPoint#distanceメソッドが実装されていても、getX(), getY()が使えるのでdistanceを迂回することができる。これらのGetterの使い方によっては、Pointは台無しになる可能性がある。

もともとこれは知ってはいたけど、実践的なノウハウは増田さんの本現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法から学んだ。判断/加工/計算を持たない、Getter/Setterのみのデータクラスは諸悪の根源であり、「第10章オブジェクト指向設計の学び方と教え方」の「古い習慣から抜け出すちょっと過激なコーディング規則」では、そのGetterとSetterに以下の弊害があると述べられている。なぜデータクラスを使うとダメなのかは、「第3章業務ロジックをわかりやすく整理する」を読むのがよいでしょう。

データクラスは諸悪の根源です。(中略)メソッドは、何らかの判断/加工/計算をしなければなりません。インスタンス変数をそのまま返すだけのgetterを書いてはいけません。インスタンス変数を書き換えるsetterはプログラムの挙動を不安定にし、バグの原因になります。

現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法

作者: 増田亨
出版社/メーカー: 技術評論社
発売日: 2017/07/05
メディア: 単行本（ソフトカバー）
この商品を含むブログ (1件) を見る

確かに、Getter, Setterは、ほとんどの場合で判断/加工/計算をしない。Pointで例でもそうだ。逆に、Point#distanceメソッドは計算をしている。ドメインオブジェクトはこういう分析の視点が反映されているべきだ。

この記事では副作用の制御が難しいSetterについて特に触れていませんが、こちらを読んでください。(Scalaのようなイミュータブルが基本の言語では、Setterはほとんど書かないので…厄介なのはGetterなのだ…)

blog.j5ik2o.me

Getter, Setterを書かないのは現実的じゃないと、まだ思っているならばActorプログラミングのコードをみてみるといい。

object Point {

  def props(x: Double, y: Double): Props = Props(new Point(x, y))

  case class Distance(x: Double, y: Double)
  case class DistanceResult(value: Double)

}

class Point(val x: Double, val y: Double) extends Actor { // 本来 val は不要

  // val state: State = ...

  override def receive: Receive = {
    case Distance(x, y) =>
     val dx = this.x - x
     val dy = this.y - y
     sender() ! DistanceResult(Math.sqrt(dx * dx + dy * dy))
  }

}

そもそもアクタープログラミングでアクターの内部状態にアクセスできない。つまり、Askしにくい。プロトコルとしてのメッセージを定義してアクターに文字通りTellすることになる。*3

object Main {

  def props(pointRef: ActorRef): Props = Props(new Main(pointRef))

  case object Start

}

class Main(pointRef: ActorRef) extends Actor {
  
  override def receive: Receive = {
     case Start =>
       pointRef ! Distance(2, 1) // !メソッドは、tellメソッドの別名！
     case DistanceResult(value) =>
       println("result = $value")
  }

}

val system: ActorSystem = ActorSystem()
val pointRef: ActorRef = system.actorOf(Point.props(1, 2))
val mainRef: ActorRef = system.actorOf(Main.props(pointRef))

// pointRef.x pointRef.yはコンパイルエラー
// pointRef.state にもアクセスできない
// そもそもActorRefからはActorの内部状態にアクセスできない

mainRef ! Start

sys.addShutdownHook{
  system.terminate()
  Await.result(system.whenTerminated, 60 seconds)
}

追記：「point1.distance(point2) で距離を取得できていたのだから、pointRef1 ! Distance(PointRef2)ではないと不公平ではないです?」という意見をもらいました。確かにそのとおり。少し書き直してみた。Getterは必要なのですが、Publicにする必要がなかったりします。

https://gist.github.com/j5ik2o/b4512b2e2e6b5343ee8ac06cdb16aa90

データクラスはAskの温床となりやすい

Tell, Don't Askのもう少しわかりやすい例を考えてみた。いつもの銀行口座の例はやめてチャットルームの例で説明してみよう。

内部にメンバ情報を持つチャットルームをモデルとして考えるとき以下のような構造を考えるだろう。これはScalaの例だけど、case classはgetterをコンパイラが自動生成なので、この例は見えないところにgetterが書かれていると思って読めばいい。そう、これは諸悪の根源データクラス。少なくともドメインオブジェクトとしては表現力が乏しく、何が出てきて何ができないかがわからない。

case class Room(id: Long, members: Set[Member])

では重要なメンバーを追加するシナリオを考えてみよう。利用者はroomのmembersに自由にアクセスできるので、以下のように状態を変えた新しいインスタンスを生成できる(copyメソッドは一部の属性を置き換えるために使います)。これはAskの例です。

val newRoom: Room = room.copy(members = room.members ++ members)

上記のようなコードが責務に含まれるという前提で考えると、ドメインオブジェクトの外に知識が分散するリスクがある。このような重要なコードは、Roomクラスのすぐ近くではなく、遠く離れたインターフェイス層やユースケース層などに現れる。つまり、Roomの全貌を理解するには、これらの散らばったコードを全て探して回り、頭の中ですべてを繋ぎ合わせる必要がある。これでは、非効率でわかりにくいコードになってしまう。

ということで、Room#addMembersメソッドを追加することになるはずだ。

case class Room(id: Long, private val members: Set[Member]) {
  def addMembers(values: Member*): Room = 
    copy(members = this.members ++ values)
}

先ほどのコードと打って変わって、呼び出し側はaddMembersと命じる(Tell)だけだ。Whatを公開してHowは隠されていてAskの例よりわかりやすい。

val newRoom = room.addMembers(newMembers)

これは頭でわかっていても、Getter,Setterを安易に記述してしまうと、それに頼ってしまい、カプセル化を破ってドメインモデルを貧血症にしてしまう。だから、ドメインモデルを設計するときは、publicなGetter/Setterを書かない方が無難でしょう。

追記：メンバーの一覧表示のユースケースがある場合は、もちろんmembersはprivateにできず、publicなGetterは必要です。そういうユースケースもない状況で、無条件にGetter/Setterを定義すると、上記のような状況に陥りやすいという主張です。

Getter/Setterを禁止するのが難しい場合

Getter/Setter禁止が現実的ではない場合、どうするとよいか。それは、このブログ記事に書きましたが、プロパティに長い名前を付けることです。例えば、breachEncapsulationOfなどのプレフィックスを付ける例です。

creators-note.chatwork.com

実はこの方法は、Ericさんが過去に関わっていたTime and Moneyのコードから借用したアイデアです。

Time & Money Code Library

例えば、CalendarDateには、カプセル化を破るが内部状態にアクセスできるメソッドがあります。

breachEncapsulationOf_day
breachEncapsulationOf_month
breachEncapsulationOf_year

Roomの例で説明すると、以下のようになる。

case class Room(id: Long, breachEncapsulationOfMembers: Set[Member])

以下のようなAskするコードは書けるけど、明らかに可読性が落ちるので、Roomの責務に応じてTellするためのメソッドを定義しよう。

val newRoom: Room = room.copy(breachEncapsulationOfMembers = room.breachEncapsulationOfMembers ++ members) // Tell形式に書き換える → val newRoom = room.addMembers(members)

とはいえ、ドメインオブジェクトをI/Oする際は、Getterがあった方がよいかもしれません。フレームワークやライブラリの都合でこのような妥協も必要な場合があります。

val json = room.breachEncapsulationOfMembers.asJson

まとめ

ということで、今日からドメインオブジェクトに安易にGetter/Setterを書くのをやめてみよう。

*1:コメントもらったけど、確かに Javaなら.class, Javadocのみの提供は完ぺきなカプセル化ですね。誤って*-source.jarを参照しないように…

*2:いや、この問題もヘッダと実装の統合がカプセル化を破る温床となった可能性があるのではないか。わざわざ、外部に存在を知らせなくてもよい知識を暴露しやすくなったのではないか、そういう個人的な疑念を持っている

*3:まぁ、アクタープログラミングでも、内部状態を取得するプロトコルを実装してしまうと同様の問題を抱えることになる…。要注意。しかし、GetするにはGet, GetResultみたいなプロトコルが必要で実装が面倒。そんなことやるぐらいなら、判断/加工/計算するプロトコルを実装した方がコスパがよい、というのはある

DDDリポジトリを楽に実装するライブラリ

2018-07-28T21:34:04+09:00

DDDのリポジトリを実装するのがダルいので、ライブラリ化したというか前から書いていたけど、Redis, Memcachedなどの実装も追加したので、簡単に説明を書いてみる。プロジェクトなどで自前で実装する際も、参照実装として参考になると思います。Scalaの例だけど、他の言語でも参考にはなるんじゃないかと勝手に想像してます。

https://github.com/j5ik2o/scala-ddd-base

デフォルトで対応している永続化技術は、以下。

JDBC
- SkinnyORM
- Slick3
NOSQL
- Memcached
- Redis
- Guava Cache
Freeモナド
- こちらは永続化そのものは行いません。上記どれかの実装に委譲することになります。

何が楽になるかというと、上記向けのリポジトリの実装があるので、Daoだけ用意すればリポジトリが実装できるようになります。

中核になるトレイト

中核となる抽象トレイトはこれ。実装はついてないです。

https://github.com/j5ik2o/scala-ddd-base/tree/master/core/src/main/scala/com/github/j5ik2o/dddbase

IOするのはAggregateです。リポジトリによっては実装するメソッドが異なるのでトレイトは細かく分かれています。Mは型コンストラクタです。

trait AggregateSingleReader[M[_]] extends AggregateIO[M] {
  def resolveById(id: IdType): M[AggregateType]
}

SkinnyORM向け実装トレイト

一例としてSkinnyORM向けに実装を提供するトレイトの説明を簡単にします。Mはここでは、ReaderT[Task, DBSession, A]としています。Taskはmonix.eval.Taskです。この型は実装ごとに変わります。たとえば、Redis向けの実装では、ReaderT[Task, RedisConnection, A]になります。

実装を提供するトレイトはAggregateIOBaseFeatureを継承しますが、ほとんどのロジックでSkinnyDaoSupport#Daoを実装したオブジェクトに委譲します。つまり、リポジトリを作る場合は、これらのトレイトをリポジトリのクラスにミックスインして、Daoの実装を提供するだけでよいことになります。

object AggregateIOBaseFeature {
  type RIO[A] = ReaderT[Task, DBSession, A]
}

trait AggregateIOBaseFeature extends AggregateIO[RIO] {
  override type IdType <: AggregateLongId
  type RecordType <: SkinnyDaoSupport#Record
  type DaoType <: SkinnyDaoSupport#Dao[RecordType]

  protected val dao: DaoType
}

trait AggregateSingleReadFeature extends AggregateSingleReader[RIO] with AggregateBaseReadFeature {

  override def resolveById(id: IdType): RIO[AggregateType] =
    for {
      record <- ReaderT[Task, DBSession, RecordType] { implicit dbSession: DBSession =>
        Task {
          dao.findBy(byCondition(id)).getOrElse(throw AggregateNotFoundException(id))
        }
      }
      aggregate <- convertToAggregate(record)
    } yield aggregate

}

実装サンプル

実装する際は、Aggregate*Featureのトレイトをミックスしてください(UserAccountRepositoryは実装を持たない抽象型です)。あとはDaoの実装の提供だけです。以下の例では、UserAccountComponentがUserAccountRecord, UserAccountDaoを提供します。

object UserAccountRepository {
  type BySlick[A] = Task[A]
  def bySkinny: UserAccountRepository[BySkinny] = new UserAccountRepositoryBySkinny
｝

class UserAccountRepositoryBySkinny
    extends UserAccountRepository[BySkinny]
    with AggregateSingleReadFeature
    with AggregateSingleWriteFeature
    with AggregateMultiReadFeature
    with AggregateMultiWriteFeature
    with AggregateSingleSoftDeleteFeature
    with AggregateMultiSoftDeleteFeature
    with UserAccountComponent {

  override type RecordType = UserAccountRecord
  override type DaoType    = UserAccountDao.type
  override protected val dao: UserAccountDao.type = UserAccountDao

  override protected def convertToAggregate: UserAccountRecord => RIO[UserAccount] = { record =>
    ReaderT { _ => // このメソッド内部でDBを利用したり、非同期タスクを実行する可能性もあるので、RIO形式を取っている
      Task.pure {
        UserAccount(
          id = UserAccountId(record.id),
          status = Status.withName(record.status),
          emailAddress = EmailAddress(record.email),
          password = HashedPassword(record.password),
          firstName = record.firstName,
          lastName = record.lastName,
          createdAt = record.createdAt,
          updatedAt = record.updatedAt
        )
      }
    }
  }

  override protected def convertToRecord: UserAccount => RIO[UserAccountRecord] = { aggregate =>
    ReaderT { _ =>
      Task.pure {
        UserAccountRecord(
          id = aggregate.id.value,
          status = aggregate.status.entryName,
          email = aggregate.emailAddress.value,
          password = aggregate.password.value,
          firstName = aggregate.firstName,
          lastName = aggregate.lastName,
          createdAt = aggregate.createdAt,
          updatedAt = aggregate.updatedAt
        )
      }
    }
  }

}

DaoはSkinnyDaoSupport#Daoを実装する形式になります。これはSkinnyCRUDMapperの派生型です。僕の場合は、ここで紹介した方法でスキーマから自動生成しています。

package skinny {

  import com.github.j5ik2o.dddbase.skinny.SkinnyDaoSupport
  import scalikejdbc._
  import _root_.skinny.orm._

  trait UserAccountComponent extends SkinnyDaoSupport {

    case class UserAccountRecord(
        id: Long,
        status: String,
        email: String,
        password: String,
        firstName: String,
        lastName: String,
        createdAt: java.time.ZonedDateTime,
        updatedAt: Option[java.time.ZonedDateTime]
    ) extends Record

    object UserAccountDao extends Dao[UserAccountRecord] {

      override def useAutoIncrementPrimaryKey: Boolean = false

      override val tableName: String = "user_account"

      override protected def toNamedValues(record: UserAccountRecord): Seq[(Symbol, Any)] = Seq(
        'status     -> record.status,
        'email      -> record.email,
        'password   -> record.password,
        'first_name -> record.firstName,
        'last_name  -> record.lastName,
        'created_at -> record.createdAt,
        'updated_at -> record.updatedAt
      )

      override def defaultAlias: Alias[UserAccountRecord] = createAlias("u")

      override def extract(rs: WrappedResultSet, s: ResultName[UserAccountRecord]): UserAccountRecord =
        autoConstruct(rs, s)

    }

  }

}

利用するときは、以下のような感じでリポジトリが返すReaderT[Task, DBSession, UserAccount]#runにDBSessionを渡すとTaskが返ってきます。それをrunAsyncするとFuture[UserAccount]が取得できます。他の実装でもほとんど同じように使えます。ご参考までに。

val resultFuture: Future[UserAccount] = (for {
  _ <- repository.store(userAccount)
  r <- repository.resolveById(userAccount.id)
} yield r).run(AutoSession).runAsync

sbtでDAOを自動生成する方法

2018-07-04T09:23:40+09:00

DDDのリポジトリを実装する際、ほとんどのケースでDAOが必要になります。が、ボイラープレートが多く、自動生成したいところです。というわけで作りました。

どうやって自動化するか

septeni-original/sbt-dao-generator

指定されたスキーマのJDBCメタ情報とテンプレートをマージさせて、ソースコードを出力します。その機能を提供するのがsbt-dao-generator¹です。つまり、sbtからコマンド一発でこういうことができるようになるわけですが、　DBのインスタンスが立ち上がっていて、スキーマ情報が組み込まれた状態でないと使えません。

chatwork/sbt-wix-embedded-mysql

sbtから組み込みMySQLを起動するプラグインです。MySQL固定です…。

flyway/flyway-sbt

こちらは言わずもがな、有名なsbtプラグイン。組み込みMySQL上にスキーマを自動作成するために使います。

環境構築手順

実際のサンプルコードは、j5ik2o/scala-ddd-baseをみてください。 flywayを扱うプロジェクトflywayとDAOを自動生成するプロジェクトexampleはわけています。

`project/plugins.sbt`

プラグインを追加しましょう

addSbtPlugin("com.chatwork" % "sbt-wix-embedded-mysql" % "1.0.9")

addSbtPlugin("jp.co.septeni-original" % "sbt-dao-generator" % "1.0.8")

addSbtPlugin("io.github.davidmweber" % "flyway-sbt" % "5.0.0")

テンプレートを作りましょう

FTLでDAOのテンプレートを書きます。以下はSkinnyORMのための例です。レコードクラスとDAOクラスです。

  case class ${className}Record(
<#list primaryKeys as primaryKey>
    ${primaryKey.propertyName}: ${primaryKey.propertyTypeName}<#if primaryKey_has_next>,</#if></#list><#if primaryKeys?has_content>,</#if>
<#list columns as column>
    <#if column.columnName == "status">
        <#assign softDelete=true>
    </#if>
    <#if column.nullable>    ${column.propertyName}: Option[${column.propertyTypeName}]<#if column_has_next>,</#if>
    <#else>    ${column.propertyName}: ${column.propertyTypeName}<#if column_has_next>,</#if>
    </#if>
</#list>
  ) extends Record

  object ${className}Dao extends Dao[${className}Record] {

      override def useAutoIncrementPrimaryKey: Boolean = false

      override val tableName: String = "${tableName}"

      override protected def toNamedValues(record: ${className}Record): Seq[(Symbol, Any)] = Seq(
<#list columns as column>       '${column.name} -> record.${column.propertyName}<#if column.name?ends_with("id") || column.name?ends_with("Id")>.value</#if><#if column_has_next>,</#if>
</#list>
    )

      override def defaultAlias: Alias[UserAccountRecord] = createAlias("${className[0]?lower_case}")

      override def extract(rs: WrappedResultSet, s: ResultName[${className}Record]): ${className}Record = autoConstruct(rs, s)


  }

特定のDAOに依存しないので、ほとんどのものに対応できるはず。以下は、Slick用とSkinny用の両方に対応したテンプレート例です。どちらでも好きなORMを使ってください。

https://github.com/j5ik2o/scala-ddd-base/blob/reboot/example/templates/template.ftl

テンプレートの書き方はこちら参照。カラム名をあらかじめプロパティ名としてテンプレートコンテキストに含めているので、簡単に書けるはずです。

`build.sbt`

flywayプロジェクト

https://github.com/j5ik2o/scala-ddd-base/blob/master/build.sbt#L114-L136

このプロジェクトではchatwork/sbt-wix-embedded-mysqlとflyway/flyway-sbtを使って自動的にスキーマを作ります。flywayMigrate := (flywayMigrate dependsOn wixMySQLStart).value としているので、sbt flyway/flywayMigrateする前に組み込みMySQLが起動します。

exampleプロジェクト

https://github.com/j5ik2o/scala-ddd-base/blob/master/build.sbt#L138-L188

JDBCの接続先設定は、flywayプロジェクトと同じ設定を指定してください。

このプロジェクトでは、septeni-original/sbt-dao-generatorを使ってJDBCメタ情報とテンプレートをマージして、DAOクラスのソースコードを生成します。今回は生成物をGitで管理したかったので、以下のようにして通常のソースコードと同じパスに出力していますが、(sourceManaged in Compile).valueを使ってtarget/src_managedに出力することも可能です。

outputDirectoryMapper in generator := {
  case s if s.endsWith("Spec") => (sourceDirectory in Test).value
  case s => new java.io.File((scalaSource in Compile).value, "/com/github/j5ik2o/dddbase/example/dao")
},

outputDirectoryMapper in generator := { className: String => (sourceManaged in Compile).value },

コンパイル時にソースコード生成するには以下のようにしてください。コンパイルと無関係に生成タスクを実行したい場合はsbt generator::generateAllとしてください。

// sourceGenerators in Compile時に出力
sourceGenerators in Compile += (generateAll in generator).value

コンパイルより前に出力したい場合は以下でも動作します。

// コンパイルより前に出力
compile in Compile := ((compile in Compile) dependsOn (generateAll in generator)).value

あとでexampleプロジェクトからflywayプロジェクトに依存することをお忘れ無く

val example = ...
dependsOn(..., flyway)

生成

コンパイル時に自動的に以下が行われます。

組み込みMySQLの起動
flyway マイグレーション実行
JDBCメタ情報とテンプレートのマージとソースファイル出力
コンパイル

実際に生成されたソースコードはこちら。

https://github.com/j5ik2o/scala-ddd-base/blob/master/example/src/main/scala/com/github/j5ik2o/dddbase/example/dao/UserAccount.scala

package com.github.j5ik2o.dddbase.example.dao

package slick {
  import com.github.j5ik2o.dddbase.slick.SlickDaoSupport

  trait UserAccountComponent extends SlickDaoSupport {

    import profile.api._

    case class UserAccountRecord(
        id: Long,
        status: String,
        email: String,
        password: String,
        firstName: String,
        lastName: String,
        createdAt: java.time.ZonedDateTime,
        updatedAt: Option[java.time.ZonedDateTime]
    ) extends SoftDeletableRecord

    case class UserAccounts(tag: Tag)
        extends TableBase[UserAccountRecord](tag, "user_account")
        with SoftDeletableTableSupport[UserAccountRecord] {
      // def id = column[Long]("id", O.PrimaryKey)
      def status    = column[String]("status")
      def email     = column[String]("email")
      def password  = column[String]("password")
      def firstName = column[String]("first_name")
      def lastName  = column[String]("last_name")
      def createdAt = column[java.time.ZonedDateTime]("created_at")
      def updatedAt = column[Option[java.time.ZonedDateTime]]("updated_at")
      override def * =
        (id, status, email, password, firstName, lastName, createdAt, updatedAt) <> (UserAccountRecord.tupled, UserAccountRecord.unapply)
    }

    object UserAccountDao extends TableQuery(UserAccounts)

  }

}

package skinny {

  import com.github.j5ik2o.dddbase.skinny.SkinnyDaoSupport
  import scalikejdbc._
  import _root_.skinny.orm._

  trait UserAccountComponent extends SkinnyDaoSupport {

    case class UserAccountRecord(
        id: Long,
        status: String,
        email: String,
        password: String,
        firstName: String,
        lastName: String,
        createdAt: java.time.ZonedDateTime,
        updatedAt: Option[java.time.ZonedDateTime]
    ) extends Record

    object UserAccountDao extends Dao[UserAccountRecord] {

      override def useAutoIncrementPrimaryKey: Boolean = false

      override val tableName: String = "user_account"

      override protected def toNamedValues(record: UserAccountRecord): Seq[(Symbol, Any)] = Seq(
        'status     -> record.status,
        'email      -> record.email,
        'password   -> record.password,
        'first_name -> record.firstName,
        'last_name  -> record.lastName,
        'created_at -> record.createdAt,
        'updated_at -> record.updatedAt
      )

      override def defaultAlias: Alias[UserAccountRecord] = createAlias("u")

      override def extract(rs: WrappedResultSet, s: ResultName[UserAccountRecord]): UserAccountRecord =
        autoConstruct(rs, s)

    }

  }

}

まとめ

このプロジェクト構成は、仕事でも結構がっつり使っていて気に入っています。スキーマ変更が起こっても、DAOは一瞬で自動生成できるので楽になると思います。興味あれば使ってみてください！

僕とセプテーニさんとコラボして作りました。↩

jupyter-scala のセットアップ方法と使い方

2018-06-18T09:48:50+09:00

セットアップ

$ pyenv install 3.6.5
$ pyenv virtualenv 3.6.5 jupyter-notebook
$ cd jupyter-scala
$ pyenv local jupyter-notebook
$ pip install --upgrade pip
$ pip install jupyter-notebook
$ wget https://raw.githubusercontent.com/alexarchambault/jupyter-scala/master/jupyter-scala
$ sh ./jupyter-scala

wgetしたjupyter-scalaのSCALA_VERSIONは以下のように2.11系なので、2.12を使う場合はコメントどおりに修正する。

SCALA_VERSION=2.11.11 # Set to 2.12.2 for Scala 2.12

起動

$ jupyter notebook

デフォルトブラウザ上で、http://localhost:8888/treeが開かれます。

使い方

New→Scalaをクリックします。

Hello Worldをやってみましょう。コードを入力したらShift+Enterで実行することができます。typoしてもセル内のコードを修正して実行し直すことができる

外部ライブラリへの依存関係を追加する

build.sbtのlibraryDependenciesに書く情報を以下の形式にして入力・評価するだけでダウンロードされます。他に依存関係を除外する$execludeもあるようです。¹

import $ivy.`org.typelevel::cats-core:1.1.0`

NOTE

load.resolverに相当するAPIがよくわからなかった。ここにResolverを追加すればよさそうではあるが、まだ試していない。

このイシューによるとload.ivyやclasspath.addなど古いAPIとのこと。↩

FluxとDDDの統合方法

2016-09-09T20:06:43+09:00

おはこんばんにちは、かとじゅんです。久しぶりにブログを書く…。最近、趣味でAngular2やらReactやらやっています。やっとWebpackになれました…。

さて、今回のお題は「FluxとDDDの統合方法」について。Angular2を先に触っていましたが、FluxといえばやはりReactだろうということで途中で浮気してReactで考えています。Angular2でもできるはずですが、今回はReactで統合方法*1について考えてみたいと思います。一つ断っておくと、FluxはDDDと統合することを想定していない設計パターンなんで云々とかはここでは考えていません。それはこのブログ記事を読む読まないに関わらずご自身で判断されてください。ソースコードについては、Githubへのリンクを一番下に書いてあるので興味がある人は参考にしてみてください。

Fluxって何？

まず基礎ということで、Flux is 何から。

本家曰く、クライアントサイドアプリケーションを構築するためにFacebookが使っているアプリケーションアーキテクチャ。図を見ればわかるように一方向のデータフローを提供するのが特徴です。Facebookが開発しているので、Reactと一緒に使われることが多いと思いますが、フレームワークというより設計パターンのようなものです。

では、Fluxの各コンポーネントの僕の解釈からということで以下を参照。

Flux | Application Architecture for Building User Interfaces

Viewはわかると思うので、Action, Action Creator, Dispatcher, Storeをみていきましょう。特にStoreってなんぞやって話が多いので整理します。Fluxについて解釈が間違っているところがあれば指摘してもらえるとうれしいです。

Action with Action Creator

Action Creatorはメソッドのパラメータからアクションを生成する、ヘルパーメソッドの集合。Actionにはタイプがアサインされ、それをDispatcherに提供する。

Dispatcher

すべてのActionは、StoreがDispathcerに登録したコールバックを経由してすべてのStoreに送られる。

すべてのActionはStoreがDispatcherに登録したコールバックを経由してStoreに送られる。
Dispatcherは、Fluxアプリケーションのためのデータフローを管理する中央ハブ的な存在で、アプリケーション固有の要件を含まないシンプルな配送システム。
Action Creatorは新しいActionをDispatcherに提供する。

DispatcherはPublisher -> (Subscriber - Publisher) -> Subscriber みたいなものですね。技術的な要件しか含まなそう。

Store

はい。よくわかんねーと言われるもの。

ストアがアクションへのレスポンス処理でストア自身を更新した後、変更イベントを送信する。

Storeはアプリケーション状態とアプリケーションロジックを表すもの。
MVCのモデル相当だが、たくさんのオブジェクト状態を管理する。ORMモデルような単一のモデルを表現しない。
TodoStoreはTodoアイテムのコレクションを管理するものに似ている。Storeはモデルのコレクションと論理領域のシングルトンなモデルの両方の表現する。
StoreはDispatcherを使って自分自身の登録とコールバックを提供する。コールバックはパラメータとしてActionを受け取る。
Storeに登録されたコールバックの内部にある、アクションタイプに基づくswitch文がActionを解釈するために使われ、適切なフックを提供する。これによって、Dispatcher経由でStoreが持つアプリケーション状態を更新できるようになる。
Storeが更新された後は、更新イベントがブロードキャストされ、ビューが新しい状態をStoreに問い合わせたり、ビュー自体を更新するかもしれない。

ここでわかることは、StoreはMVCのモデル相当ということと、アプリケーション状態とアプリケーションロジックを含むということです。このモデルの振る舞いはコールバックの中にあるということになります。

まとめると、ActionはメッセージとしてDispatcherに渡すと、ActionはDispatcher経由でStoreに送られる。Storeはアプリケーション状態を持っていて、Actionに応じた振る舞いを起こし状態を変化させる。状態変化が起こるとViewに通知される。更新の通知を受け取ったViewはStoreから状態を取り出したり、自分自身の状態を更新する可能性がある。ということになると思います。

DDDではどう考えるか？

第2部モデル駆動設計の構成要素から考えてみます。

レイヤー化アーキテクチャ

ドメイン層ビジネスの概念と、ビジネスが置かれた状況に関する情報、およびビジネスルールを表す責務を負う。ビジネスの状況を反映する状態はここで制御され使用されるが、それを格納するという技術的な詳細は、インフラストラクチャに委譲される。この層がビジネスソフトウェアの核心である。

ビジネスという言葉は少し大げさに聞こえるかもしれません。簡単に言い換えるならば、そのソフトウェアで解決すべき関心事とか知識という意味です。Todoアプリケーションならば、Todoのタイトル、期限、担当者、重要度、優先度などが当てはまるかもしれません。自分が担当しているTodoが今どれだけあるか、期限切れしているTodoは何かなどの状態を保持しています(状態の保持についての技術的都合はこの層の責務外)。そういう意味では、ソフトウェアのコアはドメインです。もう少し詳しくいうと、他のレイヤーのすべてのコンポーネントが直接的か間接的かによらずドメイン層に依存します。AngularやReactなどのフレームワークによって実装されるアプリケーションであっても、ドメイン層に従います。

アプリケーション層ソフトウェアが行うことになっている仕事を定義し、表現力豊かなドメインオブジェクトが問題を解決するように導く。このレイヤが責務を負う作業は、ビジネスにとって意味があるものか、あるいは他システムのアプリケーション層と相互作用するのに必要なものである。このレイヤは薄く保たれる。ビジネスルールや知識を含まず、やるべき作業を調整するだけで、実際の処理は、ドメインオブジェクトによって直下のレイヤで実行される共同作業に委譲する。ビジネスの状況を反映する状態は持たないが、ユーザやプログラムが行う作業の進捗を反映する状態を持つことはできる。

アプリケーション層もわかりにくいものの一つかもしれませんが、ドメインモデルの状態や振る舞いを協調動作させてアプリケーション上の一つのユースケースを実現するものです。例えば、チャットの部屋で、誰かにメンションすると、チャットというドメインモデルを更新するだけではなく、To先のユーザアカウントのデバイスセッションを探し、通知しなければならないかもしれません。これがアプリケーションロジックと言われるもので、多くの場合はユースケースを担うアプリケーションサービスの責務となります。

DDDではアプリケーション状態はドメイン層が握っていますが、もう少し詳細に述べると、集約とリポジトリというものが担っています。集約は内部にドメインモデルが複数格納されていて、それらの複数の関連をひとまとまりとして表現しています。そして、集約を永続化する際はリポジトリに依頼します。一般的に実装されるインターフェイス形式としてはput(todo: Todo)やgetByid(id: TodoId), getAll(): List[Todo] などがあります。対応する永続化デバイスもRDB版、KVS版、API版など様々ですが、外からみるとMapのように見えるインターフェイスを持っています。わざわざリポジトリが存在する理由としては、ドメインモデルはソフトウェアで解決する関心事をそのまま表現するため、永続化などの技術都合はリポジトリに移譲すべきという考えからきています。

FluxへのDDDの統合方法

では、Fluxとの統合について話しを先に進めます。FluxのStoreはリポジトリに似たような責務を持っているのは上記で述べた通りです。どちらもアプリケーション状態を保持する責務を担います。また、FluxのStoreにはアプリケーションロジックも含まれています。一方、リポジトリには集約の永続化責務しかありません。DDDではアプリケーションロジックはドメインモデルを協調動作させるアプリケーションサービスの役割でした。つまり、Flux Store = リポジトリ + 集約の協調動作(=アプリケーションサービス)と考えることができます。この時点でStoreはアプリケーション層にあると考えられます。ビジネスロジック付きの永続化アプリケーションサービスのようなものとして解釈することができます。

全体像

単純に統合するならば、FluxのStore内部でリポジトリと集約を使って、アプリケーション状態とアプリケーションロジックを実装すれば、FluxやDDDの考え方から逸脱せずに統合することが可能です。以下が統合イメージです。最初に考えたものから少し変わっていますが、根本は変わっていません。

UI層にはUIに関連するActionとAction CreatorとViewを、アプリケーション層にはDispatcherとStoreを、ドメイン層にはビジネス上の概念を表す集約(ドメインモデルをカプセル化したもの)とリポジトリを、それ以外の汎用的なものはインフラストラクチャ層に配置します。アプリケーション状態を更新したり、取得したりする際に、Store経由でリポジトリと集約を利用します。それ以外の要件(たとえばドメインモデルとは関係がないRPC呼び出しなど)は別の方法で実現することを考えていますが、長くなるので後日にします。

では、Fluxを踏まえて各層をどのように実装するか提案します。

ドメイン層

まず最初に集約を定義します。この集約は、ビジネス上の利害関係者の頭の中にある概念なので、実現方法である技術要素からできる限り独立している方がよいです。なので、ここではインフラストラクチャ(要件の影響を受けない汎用的技術基盤)となる言語機能にしか依存しないように設計します。しかしながら、今回のドメインモデルはただのデータの入れ物と化していて貧血症になっています。本来はビジネス上の豊富な知識を投影したドメインモデルとなるようにしなければいけませんが、今回の趣旨とは外れるのでご容赦くださし…。

export class TodoAggregate {
  constructor(public id: string, public text: string, public createAt: Date) {
  }
}

次にこの集約の永続化を担うリポジトリを実装します。リポジトリは集約のインスタンスを保存したり検索したりすることができます*2。インターフェイスだけを見ると集約のコレクションのように見え、内部の実装はMapであったり、ローカルストレージであったり、APIサーバであったり様々なものが実装できます。REST APIサーバから集約をI/Oしたいなら、内部の実装をHTTPクライアントに切り替える必要があるでしょう。

export class TodoRepository {

  private _todos: {[id: string]: TodoAggregate} = {};

  constructor(aggreates: TodoAggregate[] = []) {
    this.storeMulti(aggreates);
  }

  store(aggregate: TodoAggregate): void {
    this._todos[aggregate.id] = _.cloneDeep(aggregate);
  }

  storeMulti(aggreates: TodoAggregate[]): void {
    aggreates.forEach((a) => this.store(a));
  }

  resoleBy(id: string): TodoAggregate {
    return _.cloneDeep(this._todos[id]);
  }

  resolveAll(): TodoAggregate[] {
    return Object.keys(this._todos).map((id) => this.resoleBy(id));
  }

}

アプリケーション層

Storeの前にStateについて説明します。Stateには画面の入力状態以外にビューに出力するための状態として、先ほど定義したリポジトリを含めるようにします*3。

export class TodoState {

  constructor(public currentTodo: string, private _repository: TodoRepository) {
  }

  getRepository = (): TodoRepository => {
    return _.cloneDeep(this._repository);
  };

}

次はStoreです。今回はFluxUtilsのReduceStoreで実装します。肝心な部分はreduceメソッドとcreateTodoメソッドです。このコードから、アプリケーション状態はリポジトリが担っていることがわかります。今回のTodoは振る舞いがないので微妙ですが、複雑な要件であればこのドメインモデルに設計の意図を十分に表せる振る舞いが実装されるはずです。

export class TodoStore extends FluxUtils.ReduceStore<TodoState, TodoAction> {
  constructor(dispatcher: Flux.Dispatcher<TodoAction>) {
    super(dispatcher);
  }

  getInitialState(): TodoState {
    return new TodoState('', new TodoRepository());
  }

  reduce(state: TodoState, action: TodoAction): TodoState {
    switch (action.type) {
      case 'CreateTodo':
        return this.createTodo(state, action as CreateTodo);
      default:
        throw Error('no match error');
    }
  }

  private createTodo(state: TodoState, action: CreateTodo): TodoState {
    console.log(action);
    const currentTodo = state.currentTodo;
    const repository = new TodoRepository(state.getRepository().resolveAll());
    const aggregate = new TodoAggregate(new Guid().toString(), action.text, new Date());
    repository.store(aggregate);
    return new TodoState(currentTodo, repository);
  }

}

export const todoStore = new TodoStore(todoDispatcher);

Dispatcherが抜けていた…。以下の一行です。

export const todoDispatcher = new Flux.Dispatcher<TodoAction>();

UI層

いよいよ、Reactのコンポーネントの結合ですが、最初にビューモデルを作ります。このモデルはビューに関連する知識を表しています。集約などのドメインモデルは、実際のビジネスなどの問題領域の概念と対応付きますが、ビューでは異なる表現形式が必要になる場合があります。集約のモデルを画面によって形式を変えて出力する場合などです。ビューモデルの生成はいろいろやり方がありますが、ここではConverterを使って集約から変換して導出します。

export class TodoViewModel {
  constructor(public key: string, public text: string, public dateString: string) {
  }
}

Converterのコードは以下。リポジトリが持つ集約の集合をビューの要件に合わせてmapしているだけです。

export class TodoViewModelConverter {

  constructor(private _repository: TodoRepository) {
  }

  getTodoVMs = (): TodoViewModel[] => {
    return this._repository.resolveAll().map((a) => {
      return new TodoViewModel(a.id, a.text, a.createAt.toLocaleDateString() + " " + a.createAt.toLocaleTimeString());
    });
  };

}

最後に、React.Componentです。このコンポーネントはAction CreatorとStore(リポジトリ含む)にしか依存していません。 View自身も状態を持っていますが、UI上の何かのイベントが起こるとAction Creatorを使ってActionをDispatcherに送信します。すると、Storeで振る舞いを起こし状態変化が起こり、ViewがStoreにあらかじめ登録したハンドラが呼ばれてView自身の状態を書き換えます。

export class TodoComponent extends React.Component<{}, TodoState> {

  private listenerSubscription: { remove: Function };

  constructor(props: {}) {
    super(props);
    this.state = new TodoState('', new TodoRepository());
  }

  componentDidMount() {
    this.listenerSubscription = todoStore.addListener(this.handleStateChange.bind(this));
  }

  componentWillUnmount() {
    this.listenerSubscription.remove();
  }

  handleStateChange() {
    const storeState = todoStore.getState();
    const newRepository = new TodoRepository(storeState.getRepository().resolveAll());
    const newState = new TodoState(storeState.currentTodo, newRepository);
    this.setState(newState);
  }

  handleValueChange(event: React.SyntheticEvent) {
    const todoText = (event.target as HTMLInputElement).value;
    this.setState(new TodoState(todoText, this.state.getRepository()));
  }

  handleClick() {
    TodoActionCreator.createTodo(this.state.currentTodo);
  }

  render(): JSX.Element {
    const todos = new TodoViewModelConverter(this.state.getRepository()).getTodoVMs();
    return <div>
      <input type='input' value={this.state.currentTodo} onChange={this.handleValueChange.bind(this)}/>
      <button onClick={this.handleClick.bind(this)}>Update</button>
      <div>
        {todos.map((a) => {
          return <p key={a.key}>{a.text} : {a.dateString}</p>;
        })}
      </div>
    </div>;
  }
}

コードはGithubにあります。リポジトリがメモリ版なのでそれをAPI版に返れば複数ユーザで特定のアプリケーション状態を共有できるようになるはずです。

以上、長くなりましたが、ReactでのFluxとDDDの統合方法の解説でした！統合方法は他にもいろいろあると思いますが、僕が考える一例を示してみました。

次はAngular2版をまとめてみます。

*1:今回はEvent Sourcingではありません。State Sourcingです。機会があれば実装例を作ります

*2:ActiveRecordのようにドメインモデルが永続化機能を持たないのはなぜか？という疑問があるかもしれません。ドメインモデルはビジネス上の概念と紐付くものなので、なるべく固有の技術から依存性を排除しビジネス上の知識を表現します

*3:Scalaのケースクラスのcopyメソッドがほしい…。インスタンスの入れ替えとか面倒なので

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

2016-03-07T03:46:46+09:00

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

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

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

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

レイヤー化アーテクチャの目的

第2部第4章ドメインを隔離するからの引用。

まず、問題提起から

UI, DBおよびその他の補助的なコードがビジネスオブジェクトに直接書かれることがしばしばある。また、ビジネスロジックが新たに追加される時には、UIウィジットやデータベーススクリプトのふるまいに組み込まれてしまう。こういうことが起きるのは、短期的に見ると、動くようにするには最も簡単な方法だからだ。ドメイン関連のコードがそうした膨大な他のコードの中に拡散してしまうと、コードを見て意味を理解するのがきわめて困難になる。

解決方法は以下。

複雑なプログラムはレイヤーに分割すること。各レイヤで設計を進め、凝集度を高めて下位層にだけで依存するようにすること。ドメインモデルに関係するコード全部を１つの層に集中させ、UI、アプリケーション、インフラストラクチャのコードから分離すること。表示や格納、アプリケーションタスク管理などの責務から解放されることで、ドメインオブジェクトはドメインモデルを表現するという責務に専念できる。これによて、モデルは十分豊かで明確になるように進化し、本質的なビジネスの知識をとらえて、それを機能させることができるようになる。

ここでは簡単にいうとドメインを隔離することが第一義的と言っています。

レイヤーの内訳

レイヤーは大きく分けて以下に分かれます。

インターフェイス層(UIなど)
アプリケーション層
ドメイン層
インフラストラクチャ層

ここでは、同じく引用からアプリケーション層とドメイン層、インフラストラクチャ層の責務の違いを説明します。

アプリケーション層とは

ソフトウェアが行うことになっている仕事を定義し、表現力豊かなドメインオブジェクトが問題を解決するように導く。このレイヤが責務を負う作業は、ビジネスにとって意味があるものか、あるいは他システムのアプリケーション層と相互作用するのに必要なものである。このレイヤは薄く保たれる。ビジネスルールや知識を含まず、やるべき作業を調整するだけで、実際の処理は、ドメインオブジェクトによって直下のレイヤで実行される共同作業に移譲する。ビジネスの状況を反映する状態は持たないが、ユーザやプログラムが行う作業の進捗を反映する状態を持つことはできる

ドメイン層とは

ビジネスの概念と、ビジネスが置かれた状況に関する情報、およびビジネスルールを表す責務を負う。ビジネスの状況を反映する状態はここで制御され使用されるが、これを格納するという技術的な詳細は、インフラストラクチャに委譲される。この層がビジネスソフトウェアの核心である

インフラストラクチャ層とは

上位のレイヤーを支える一般的な技術的な機能を提供する。これには、アプリケーションのためのメッセージ送信、ドメインのための永続化、ユーザインターフェイスのためのウィジット描画などがある。インフラストラクチャ層は、ここで示す4層間における相互作用のパターンも、アーキテクチャフレームワークを通じてサポートすることがある。

ドメインサービスとは

それでは、各レイヤーのサービスについて説明する前に、ドメイン層のドメインサービスの概念について触れておきます。あくまでドメインサービスの話です。

問題提起：

ドメインから生まれる概念の中には、オブジェクトとしてモデル化すると不自然なものもある。こうしたドメインで必要な機能をエンティティや値オブジェクトの責務として押し付けると、モデルに基づくオブジェクトの定義を歪めるか、意味のない不自然なオブジェクトを追加することになる

解決方法：

ドメインにおける重要なプロセスや変換処理が、エンティティや値オブジェクトの自然な責務でない場合は、その操作は、サービスとして宣言される独立したインターフェイスとしてモデルに追加すること。モデルの言語を用いてインターフェイスを定義し、操作名が必ずユビキタス言語の一部になるようにすること。サービスには状態を持たせないこと。

具体的な例で考えてみましょう。コード例は、以前のエントリから引用します。口座間転送のサービスです。転送メソッドは、MoneyにもBankAccountにも従属できないので、ドメインサービスとしています。あまり適切な例ではないかもしれませんが、万人ウケする事例はないので…。

口座間送金サービス
ServiceとDCIについて - かとじゅんの技術日誌

object TransferDomainService {
  // 送金する
  // - 振る舞いの名前はユビキタス言語と対応する
  // - 原則的にステートレスであること
  def transfer(money: Money,
               from: BankAccount,
               to: BankAccount): (BankAccount, BankAccount) = {
    require(from.balance >= money)
    val newFrom = from.decrease(money)
    val newTo = to.increase(money)
    (newFrom, newTo)
  }
}

呼び出し例

TransferDomainService.transfer(money, from, to)

このコードを見てもらうと、"なんだドメインモデルを入出力にとる関数じゃないか" と思うでしょう。そのとおりです。最初はその程度の認識でよいと思いますが、ここで一点だけいいたいのは、乱用は禁止ということです。ドメインサービスは、単に関数を導入をすればいいというものでありません。ドメインで必要な振る舞いであるが、無理矢理エンティティや値オブジェクトの振る舞いとすることで、ビジネス上の知見を歪める設計になるということです。また、逆に、従属するエンティティや値オブジェクトがないということで早期あきらめてしまい、なんでもかんでもドメインサービスにするというのもの違うのです。後者の場合は、振る舞いがあるべきドメインモデルから振る舞いを奪うことになるので、ドメインモデル貧血症の温床になる可能性があるのです。いずれにしても、ユビキタス言語のセマンティクスに従う必要があるということですね。十分な考慮なしに乱用は厳禁です。

アプリケーションサービスの事例

前置きはさておき、アプリケーション層のアプリケーションサービスの違いを考えてみましょう*1。以下の例は、上記のドメインサービスを利用したアプリケーションサービスの例です。

case class TransferDto(money: Money, fromId: BankAccountId, toId: BankAccountId)

object TransferApplicationService {
 
  def transfer(transferDto: TransferDto): Try[Unit] = { 
    DB.localTx{ implicit tx =>
      for {
        Seq(from, to) <- BackAccountRepository.resolveBy(transferDto.fromId, transferDto.toId)
        (newFrom, newTo) = TransferDomainService.transfer(money, from, to)
        storeResult = BankAccountRepository.store(newFrom, newTo)
        Seq(fromUA, toUA) <- UserAccountRepository.resolveByBankAccountIds(transferDto.fromId, transferDto.toId)
        result <- NotifyInfrastructureService.notify(storeResult, fromUA.mailAddress, toUA.mailAddress)
      } yield result
    }
  }

}

ドメインサービスとアプリケーションサービスの違い

ドメインサービスはドメインモデルを入出力にとる関数ですが、それだけではアプリケーション要件は実現できません。そもそもアプリケーションサービスの入出力が違うわけです。アプリケーションサービスはI/F層から利用される前提であるため、TransferDtoはユースケースに強く依存することになります。また、I/Oの整合性を保証するためのトランザクション制御や、特定の処理完了を告げるためにプッシュ通知サービスを呼び出したりすることがあります*2。もちろん、単純なユースケースであれば、コントローラなどにこのようなロジックを直接書くかもしれないが、意図をより明確にするには別の名前をつけたメソッドに切り出したりします。この考え方をより推し進めたのがアプリケーションサービスです。

DDDでは、ドメインサービスはユビキタス言語に基づくビジネスロジックを表現しています。一方、アプリケーションサービスはビジネスロジックそのものではないという定義です*3。あくまで、ドメインモデルやインフラストラクチャサービスなどのやるべき作業を調整し進捗管理をするためだけの存在なのです。ユビキタス言語上の振る舞いと、アプリケーション上のユースケースという関係性とでも言えばよいでしょうか？この言葉だけでも、粒度が違うことが理解できると思います。この例ではリポジトリを使って現在の集約(=グローバルな識別子を持つエンティティ)を読み込んでドメインサービスの結果をまた保存しています。このI/Oはドメインモデル(エンティティ, 値オブジェクト, ドメインサービス)自体ので責務*4ではなく、リポジトリの責務なのでドメインサービスが担えないと考えています。

というわけで、ドメインサービスとアプリケーションサービスは、役割からして全く違うものです。

ドメインサービスのメソッドはユビキタス言語に結びついていることが前提です。ビジネス上の知識が単に振る舞いとなっているだけですが、重要なのは名前だけでなくその裏に秘められた不変条件です。口座間送金の場合はfromからtoに必ずお金が移動することです。

仮に TransferDomainService.transfer(money, from, to) メソッドの呼び出し部分が

newFrom = from.decrease(money)
newTo = to.increase(money)

であってもこのようなアプリケーションサービスは必要になるかもしれない。僕の経験ではほとんど必要になります。繰り返しになりますが、役割が違うから必要になるというわけです。もし、ドメインサービスにプッシュ通知などの通知機能が含まれているとしたら、それはドメイン知識と関係があるのか？それはユビキタス言語に含まれるのか？という問いをした方がよいでしょう。仮に、混同しているようなら、ドメインは隔離できていないということになります。

Akka で番外編

ここから番外編。AkkaでのCQRS+ESを前提にしているので理解しにくいと思った方は無理に読まなくてもよいと思います。

PersistentActorを使って集約やドメインサービス、アプリケーションサービスを実装した場合の擬似コードを書いてみた。あくまで概念を理解してもらうためのコードなので、すべてのコードは記載していませんし、コンパイルできないとか、集約がなぜActorRefなのかなど、そういう細かい点は無視して下さい。

CQRS + ESになるとドメインモデル群は書き込み系にしか登場しませんが、読み込みは別の系になります。集約を読み込むことを考えると伝統的なスタイルではリポジトリを実装することになりますが、CQRSでは集約は基本的にキーバリューのデータ構造として保存できればいいと見なすことができます。

AkkaではPersistentActorにコマンドを投げてその時の状態変化の記録としてドメインイベントを追記保存していくことになります*5。蛇足ですが、集約はドメインモデルなのになぜ永続化機能も持つの？という疑問にだけ答えておくと、集約内部のルートとなるエンティティに代表されるドメインモデルには永続化機能がなくて、ライフサイクルを司る集約にだけ永続化機能があるという考え方です。以下の例では、開始と終了イベントしか永続化していません*6が、リポジトリでいうstoreの機能はAkkaが担っていることになります。

そうなるとドメインサービスとアプリケーションサービスはほぼ同じようなものになるのでは？という見方になると思いますが、微妙に要件(以下の例では通知サービスの呼び出しがある)が異なるのでそうもいかないというのがわかると思います。

// ドメインサービス
class TransferDomainService extends PersistentActor {

   var state: Option[TransferState] = None

   // snip

   override def receiveCommand = {
     case BankAccountIncreased(toRef) =>
        val (commandId, fromRef, toRef, money) = state.map( e => (e.fromRef, e.toRef, e.money) ).get
        persist(DomainTransferFinished(EventId(), commandId, fromRef, toRef, money)) { ev =>
          eventBus.unsubscribe(Topic(classOf[BankAccountIncreased], toRef))
          eventBus.publish(Topic(ev, Some(ev.commandId)) // 終わったら完了イベントを発火
        }
     case BankAccountDecreased(fromRef) =>
        eventBus.unsubscribe(Topic(classOf[BankAccountDecreased], fromRef))
        val toRef = state.map(_.toRef).get
        toRef ! Increase(state.map(_.money).get) // BankAccount に Increase メッセージをパッシング。状態の永続化も行われます。
     case Transfer(commandId, money, fromRef, toRef) =>
        persist(DomainTransferStarted(EventId(), commandId, fromRef, toRef, money)) { ev =>
          state = Some(TransferState(commandId, fromRef, toRef, money))
          eventBus.subscribe(Topic(classOf[BankAccountDecreased], fromRef))
          eventBus.subscribe(Topic(classOf[BankAccountIncreased], toRef))
          fromRef ! Decrease(money) // BankAccount に Decrease メッセージをパッシング。状態の永続化も行われます
          eventBus.publish(ev) // 開始イベントを発火
        }
   }

}

// アプリケーションサービス
class TransferApplicationService extends PersistentActor {

  // snip

  override def receiveCommand = {
     case NotifyCompleted(_, commandId) =>
       persist(ApplicationTransferFinished(EventId(), commandId, fromId, toId, money)) { ev =>
         eventBus.unsubscribe(Topic(classOf[NotifyCompleted], commandId))
         eventBus.publish(ev) // 終了イベントを発火
       } 
     case DomainTransferFinished(_, commandId, fromId, toId, money) => // ドメインロジックが完了したら
       eventBus.unsubscribe(Topic(classOf[TransferFinished], commandId))
       eventBus.subscribe(Topic(classOf[NotifyCompleted], commandId))
       notifyService ! Notify(commandId, fromId, toId, money) // 通知サービスを呼び出す
     case ApplicationTransfer(commandId, money, fromId, toId) =>
       persist(ApplicationTransferStarted(EventId(), commandId, fromId, toId, money)) { ev =>
         eventBus.subscribe(Topic(classOf[TransferFinished], commandId))
         val fromRef = context.actorSelection(s"/user/${fromId}").resolveOne() // リポジトリから参照を取得する処理に相当する
         val toRef = context.actorSelection(s"/user/${toId}").resolveOne() // リポジトリから参照を取得する処理に相当する
         transferRef ! Transfer(commandId, money, fromRef, toRef) // ドメインサービスを呼び出す
         eventBus.publish(ev) // 開始イベントを発火
       } 
  }

}

*1:混同の対象はアプリケーションサービスとドメインサービスとしているので、インフラストラクチャ層のインフラストラクチャサービスは特に触れません。

*2:この例では、DBやNotifyInfrastructureServiceが、アプリケーション固有ではなく一般的な技術基盤としてのインフラストラクチャサービスと位置づけています

*3:ビジネスにとっては必要不可欠であることは間違いないですが。

*4:ドメインモデルはユビキタス言語に即した表現を行うのが責務なので永続化は責務対象外としている

*5:エラー時のロールバックはこの例では考慮していません

*6:開始イベントは利用してないのでいらないかも。

かとじゅんの技術日誌

Rustでブロッキングキューを実装する

まず作るな・既存のコードを調査しろ

BlockingQueueのインターフェイス

データ構造

putメソッド

putのテスト

putの実装

takeメソッド

takeのテスト

takeの実装

putとtakeの相互作用

whileをなぜ使うのか

中断機構

check_and_update_interrupted

interrupt

is_interrupted

tokio版の実装

まとめ

Scala 3でデータ指向プログラミングは可能か

原則1 「コード(動作)をデータから切り離す」

データの定義

コードの定義

原則2「データを汎用的なデータ構造で表す」

原則3 「データをイミュータブル(不変)として扱う」

原則4 「データスキーマをデータ表現から切り離す」

Cart型, Order型

まとめ

付録

RustでProperty-based testing ライブラリを実装してみた

Property-based testingとは

実装はしたくない使いたいという人はこっち

実装したクレートについて

なにがうれしいのか

Genの利用方法

参考にした実装

実装コード

for_all_gen関数とtest_with_prop関数

GenとGenを生成するファクトリGens

Gens#pure

Gens#one_char

Gens#list_of_n

Gens#choose

Gens#one_of

Gens#frequency

まとめ

メモ:値オブジェクトの定義と差異について

Wikipediaの値オブジェクト

PofEAAの値オブジェクト

「PofEAAの値オブジェクト」にDTOは含まれるか

「IDに基づいた等価性を確保していない」以外の特徴はあるのか

「PofEAAの値オブジェクト」に「DDDの値オブジェクト」は含まれるか

DDDの値オブジェクト

「DDDの値オブジェクト」の特徴

特徴の比較

差異の解釈

まとめ

追加資料

『エリック・エヴァンスのドメイン駆動設計』

補足: 大前提であるドメインと境界づけられたコンテキストについて

補足

補足

感想

『Domain-Driven Design Reference』Definitions and Pattern Summaries

『実践ドメイン駆動設計』

感想

『セキュア・バイ・デザイン』

感想

『Patterns, Principles, and Practices of Domain-Driven Design』

感想

『Learning Domain-Driven Design』

感想

『現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法 』

感想

『ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本』

感想

『良いコード／悪いコードで学ぶ設計入門保守しやすい 成長し続けるコードの書き方』

感想

『ドメイン駆動’設計 モデリング・実装ガイド』

感想

『現場で役立つシステム設計の原則〜変更を楽で安全にするオブジェクト指向の実践技法』

『ドメイン駆動設計入門ボトムアップでわかる！ドメイン駆動設計の基本』

『良いコード／悪いコードで学ぶ設計入門保守しやすい　成長し続けるコードの書き方』

『ドメイン駆動’設計モデリング・実装ガイド』

『ドメイン駆動設計サンプルコード&FAQ』

`or`パーサー

`and_then`パーサー

`Parser`型

`elm_pred_ref`, `or`, `and_then`の実装

`elm_pred_ref`の実装

`or`の実装

`and_then`の実装

`flat_map`, `map`, `successful`, `failed` の実装

`ParsersImpl#flat_map`

`ParsersImpl#map`

`ParsersImpl#successful`

`ParsersImpl#failed`

`SkipParsers#skip_left`, `skip_right`, `surround`