Introduction to the practice Reactive-DDD

Transcript

1. Introduction to the practice of Reactive DDD Junichi Kato (@j5ik2o)

   リアクティブDDD実践入門

2. Self Introduction • Approximately 7 years Scala experience • A

   backend software engineer at ChatWork: ◦ Tech lead, Architect, DDD evangelist ◦ ChatWork: the largest "business chat" service in Japan 自己紹介。ChatWorkでエンジニアとして働いています

3. Agenda • Objective ◦ Understanding Reactive DDD by a concrete

   example using Akka • Contents ◦ What is Reactive-DDD ◦ Explaining Reactive-DDD using a simulated project ▪ Domain Modeling ▪ Command stack ▪ Query stack ▪ Controller ▪ Read-model updater(RMU) ◦ Conclusion アジェンダ

4. What is Reactive-DDD • Vaughn Vernon's definition: Reactive-DDD means combining

   Actor and DDD.The objective is to eliminate the architecture overhead. The references are in the followings: ◦ Vaughn Vernon: Reactive Domain-Driven Design - InfoQ ◦ Reactive DDD with Scala and Akka • The benefits are not only being Message-driven, but also Resilient, Responsive, and Elastic.Reactive-DDD may be Reactive System + DDD? • In Scala, Akka is one of the best options to construct CQRS+ES system based on DDD リアクティブDDDについて

5. Explain Reactive-DDD using a simulated project 模擬プロジェクトで解説

6. Bank account API server • Bank Account API server that

   can deposit and withdraw money ◦ Deposit to a bank account ◦ Withdraw from a bank account ◦ Refer to transaction(deposit or withdraw) histories • Source ◦ https://git.io/reactive-ddd-example 銀行口座APIサーバの例 // Deposit to a bank account $ curl -X PUT \ http://localhost:8080/bank-accounts/XEe/events \ -H 'content-type: application/json' \ -d '{ "type": "deposit", "amount": 1000, "currencyCode": "JPY" }' {"id":"XEe","errorMessage":null}% // Refer to transaction histories on a bank account $ curl -X GET \ http://localhost:8080/bank-accounts/XEe \ -H 'content-type: application/json' { "id": "XEe", "values": [ { "type": "deposit", "amount": 1000, "currencyCode": "JPY", "createAt": 1520219459 } ], "errorMessage": null }

7. System configuration • CQRS+ES(Event Sourcing) • Separate DB to Write

   and Read • Write - Read Flow ◦ API(Write) →WriteDB→RMU→ReadDB→ API(Read) • Actor based implementation 想定するシステム構成 Write DB Read DB API RMU Command Query Domain Event Read Model Domain Event SQL

8. Key design elements • Explain the following design elements in

   order キーとなる設計要素を順に説明 Domain modeling Command stack Query stack Controller Read-model updater

9. 〜Domain modeling〜 ドメインモデルの設計

10. Explore domain models • Explore domain model candidates from words

    in requirements ◦ A customer wants to deposit to his bank account, or withdraw from it ◦ A customer wants to refer to transaction histories in his bank account • Domain model candidates ? ◦ Customer ◦ BankAccount ◦ Deposit, Withdraw ◦ TransactionHistory • Analyze the domain model from use cases ドメインモデルを探索する Customer BankAccount Deposit Withdraw Transaction History

11. Bank Account API Server Target use cases • The target

    use cases are in the followings 対象のユースケース Deposits/Withdraws to his own bank account Refers to transaction histories in his own bank acount A Customer

12. Use case analysis(1/2) • A customer deposits to his own

    bank account ◦ In deposit screen(B), a customer(A) ▪ puts money in ATM. ▪ inputs(C) amount(E) of money(E). ▪ clicks(C) confirm button. ◦ The system(A) ▪ confirms(C) money(E). ▪ deposits(C) it to his own bank account(E). ▪ saves(C) his own bank account(E) state. • Same in withdraw case ユースケース分析(1/2) • Annotations ◦ A = Actor in use-case ◦ BCE stereotypes ▪ B = Boundary, interfaces for actor ▪ C = Control, software-functions ▪ E = Entity, domain objects

13. • A customer refers to transaction histories in his own

    bank acount ◦ A customer(A) ▪ puts(C) his own bank book(E) in ATM ▪ clicks(C) button for it ◦ The system ▪ reads(C) transaction histories(E) in his own bank account(E) ▪ updates(C) the bank book(E) Use case analysis(2/2) ユースケース分析(2/2) • How to analyze BCE ◦ Nouns are domain model candidates, or the ‘properties’ ◦ Verbs tend to be 'methods' or 'relations' • Terms not subject to systematization are irrelevant • UI and I/O elements are irrelevant as well

14. Noteworthy analytical elements • Domain model candidates ◦ Bank Account(E)

    ▪ Bank Account ID ▪ Current Balance(unnecessary?) ◦ Transaction History(E) ▪ Occurred Date ▪ Deposit or Withdraw type ▪ Amount of money 注目すべき分析要素 • Control candidates ◦ Deposit ◦ Withdraw

15. Boundary of Aggregate definition • The responsibility of the Aggregate

    ◦ maintain consistency, suppress direct relations to increase. • Boundary ◦ All objects that cannot exist without a bank account are included in Bank Account Aggregate. ◦ Is Transaction History Aggregate? Or is it an object inside Aggregate? ◦ Obviously a search for transaction history requires a bank account, but Aggregate with whole histories may consume huge memories. In this case, prefer on-demand DB queries to object references 集約境界の定義 BankAccount BankAccountId BankAccountName balance: Money BankAccountEvent BankAccountEventId Deposit or Withdraw amount: Money occurredAt: DateTime ?

16. Separate Read/Write responsibilities in Aggregate 集約上のR/W責務の分離 BankAccount • Separate query

    responsibility from Aggregate, Aggregate concentrates on command responsibility. • Domain events that occurred in Aggregate are persisted and are used for query responsibilities • Not necessary to include BankAccountEvent by this responsbility separation. state transition Command side Query side BankAccountEvent BankAccountEventRecord RMU Dao, Record Write DB R/W separation Read DB

17. Allocating behaviors to domain models • Focus on Entities and

    Controls ◦ BankAccount and Deposit/Withdraw • Controls are analyzed as the message to Entities • Then find the appropriate Entity to receive the Control ◦ Deposit/Withdraw is sent to BankAccount • This analysis is reflected to code ◦ bankAccount.deposit(amount, …) ◦ bankAccountRef ! Deposite(amount, ...) ドメインモデルへの振る舞いの割り当て Deposit or Withdraw Bank Account Transition state

18. Does BankAccount itself work? • Avoid dispersal of knowledge by

    behavior concentration to entities.But does BankAccount itself work? • How did Alexander analyze the kettle? ◦ A kettle is just a container to store water? ◦ He analyzed the object to inform the boiling of water • The analysis result changes depending on what kind of responsibility is given to the object 銀行口座自身が動作するのですか？ just a container to store water? An object to inform the boiling of water

19. 〜Command Stack〜 コマンドスタック

20. Layered Architecture • Projects based on Clean Architecture ◦ be

    simpler than the traditional layer style • Direct dependency from outside to inside • If use interface from use case, use indirect dependency • Layers ◦ Interface layer ▪ HTTP, DB, Aggregates ◦ Use case layer ▪ Roles to combine tasks for workflow ◦ Domain layer ▪ domain objects レイヤ化アーキテクチャ

21. Layered Architecture example • sbt project as a layer is

    one of approaches to the layered architecture プロジェクト構成の例 interface use-case domain infrastructure controller write use case read use case domain object aggregate dao, record port port(impl) port port(impl) command stack query stack

22. コマンドスタックの設計 interface use-case domain infrastructure controller write use case read

    use case domain object aggregate dao, record port port(impl) port port(impl) command stack query stack Designing command stack

23. Domain object and Aggregate • Domain objects are the state

    of Aggregate • Domain objects are simple objects represented by case classes and basic data types • The internal state encapsulation by using Actors ◦ The internal state can only be manipulated via messages ドメインオブジェクトと集約の関係 BankAccountAggregate(akka-actor) state: BankAccount(Entity) id: BankAccountId(VO) name: BankAccountName(VO) balance: Money(VO)

24. Domain object example ドメインオブジェクトの例

25. Stored domain events Aggregate design • Aggregate is a Persistent

    Actor(stateful actor) • Create a initial state by `OpenRequest` • Use `DepositRequest` or `WithdrawRequest` to update the state. Also return the latest state for assertion. • After receiving the command, change the state and persists the domain events • Use Domain Events for Actor replaying 集約の設計 BankAccountAggregate BankAccount DepositeRequest DepositSucceede d Opened Deposited Withdraw change the state persist domain events return the response Append only persist replay

26. Domain Event Design • Use Domain Events not only for

    actor replaying but also for systems integration (e.g. Read Model Updater) • Use Domain event names in terms of domain knowledge, not terms for persistence ◦ Opened ◦ Deposited ◦ Withdrawn ◦ Closed ドメインイベントの設計

27. Domain Event example ドメインイベントの例

28. Aggregate example(1/4) • Implement Persistent Actor • Actor state type

    is domain object • persistenceId is a string value combine aggregate name and id • Release system resource by receive timeout 集約の例(1/5) aggregate-name + id number Handle the state of domain object

29. Aggregate example(2/4) • Implement `receiveCommand` • After receiving commands, persist

    domain events(persist method) • `tryToSaveSnapshot` persists the latest state at that time • Also reply the response for the request 集約の例(2/5)

30. Aggregate example(3/4) • Implementation for deposit and withdraw • The

    persisted format and storage depend on the akka-persistence plugin and its settings • In this time, akka-persistence-jdbc 集約の例(3/5)

31. Aggregate example(4/4) • Use `receiveRecover` to replay actor from Domain

    Events • Complete recovery when `RecoveryCompleted` is received • Accelerate actor replaying by using events and the latest snapshot. • When SnapshotOffer, overwrite the state completely 集約の例(4/5)

32. Configurations for Aggregate • Configurations for akka-persistence-jdbc • Persist Domain

    Events to message column by Serializer, snapshot is into snapshot column 集約の設定(1/2)

33. Testing Aggregate • Testing to stop/restart a persistent actor with

    state • Replay the actor state across runtime 集約のテスト Replay actor state from events Persist domain events

34. akka-persistence benefits • No need to implement DDD Repository: ◦

    akka-persistence provides entity writing functions ◦ ActorSystem(#actorSelection, #actorOf) provides entity reading functions ◦ Other query methods are in the query stack • In-memory states act as cache ◦ No need to poll the DB because the Actor keeps the latest state ◦ Events is appended to journals, the state is restored from the log at restart • However, the scaling strategy for stateful actors is required. For example use the following: ◦ akka-cluster, akka-cluster-sharding • In this time, use akka-cluster-sharding akka-persistenceのメリット

35. Node Shard Sharded Aggregate design (1/2) • Sharding BankAccountAggregate by

    akka-cluster-sharding 分散された集約の設計 Node Shard … ShardedBankAccount Aggregate BankAccount ShardRegion ShardedBankAccountAggregates(proxy) ShardRegion REST I/F ShardCoordinator (Cluster Singleton) Shard Shard … … ShardRegion forwards commands to actors distributed on each Shard. ... ... ShardCoordinator manages Shard locations for ShardRegion.

36. Sharded Aggregate Design(2/2) 分散された集約の設計 • Distribute stateful actors on each

    Shard by akka-cluster-sharding • Start ShardRegion on each node. Use it to forward command to stateful actors • Use ShardRegion.ExtractEntityId to extract the entity id from the command • Use ShardRegion.ExtractShardId to extract the shard id from command

37. Sharded Aggregate example(1/2) 分散された集約の例 • Override `unhandled` to add support

    for receive timeout behavior • Send `Passivate` to Shard actor if no messages, then stop this actor received `StopBankAccount` from Shard actor

38. Sharded Aggregate example(2/2) 分散された集約の例 • ShardedBankAccountAggregates encapsulates ShardRegion from the

    caller. It acts like a proxy • Start ShardRegion when proxy is created • Forward the received message to ShardRegion • Note that it uses ClusterSharding# start instead of ActorSystem#actorOf

39. Designing write use case • Provide methods to execute use

    cases • the methods are a combination of akka-stream and Aggregate • The use case is pipe-line to execute tasks, Not I/O responsebility • I/O is supported by interface ports 集約用ユースケースの設計 Interface Layer UseCase Layer BankAccountAggregateFlowsImpl BankAccountAggregateFlows BankAccountAggregateUseCase BankAccountAggregates Domain Layer BankAccount ShardRegion BankAccountAggregate Output port

40. Write use case example(1/2) 集約用ユースケースの例 • Implement use cases to

    support command operations only • Enqueue requests and `Promise` object for response • Promise completes after processing the request • Use Aggregate via interface ports

41. Write use case example(2/2) 集約ユースケースの例 • The Queue element type

    is Request and Promise[Response] • Execute sink to complete Promise after Aggregate flow Use Aggregate via interface ports The openBankAccountQueue is a long running stream

42. Interface port example インターフェイスポートの例 • Implement interface port • The

    parameter types and return types of the methods depends on Use case layer • However the implementation depend on interface layer • Use ask pattern to combine Aggregate in the stream easily. Interface port(I/F) in use case ask to Aggregate

43. 〜Query stack〜 クエリスタック

44. クエリスタックの設計 interface use-case domain infrastructure controller write use case read

    use case domain object aggregate dao, record port port(impl) port port(impl) command stack query stack Designing query stack

45. Read model example • Designing read-models based on the domain

    events リードモデルの例 generate read-models auto generated using septeni_orignal/sbt-dao-generator Persist the latest sequence number in consideration of process stop

46. Designing read use case • Support reading operations only •

    Use DAOs via interface ports リードモデル用ユースケースの設計 Interface Layer UseCase Layer BankAccountReadModelFlowsImpl BankAccountReadModelFlows BankAccountReadModelUseCase BankAccountDao, BakAccountEventDao(by slick) Output port

47. Read use case example • Same as the use case

    of Aggregate リードモデル用ユースケースの例

48. Interface port example • read read-model by using Slick3 DAO

    リードモデル用のポートの実装

49. 〜Controllers〜 コントローラ

50. Controller desgin • The controller has akka-http routes • The

    route invokes use case methods • No ports because direct dependency is available コントローラの設計 Interface Layer UseCase Layer BankAccountReadModelUseCase Routes extends BankAccountController BankAccountAggregateUseCase

51. クエリスタックの設計 interface use-case domain infrastructure controller write use case read

    use case domain object aggregate dao, record port port(impl) port port(impl) command stack query stack Designing controllers

52. Controller example • Combine the future of use case and

    akka-http route コントローラの例 Command Query

53. 〜API Server〜 APIサーバのブートスラップ

54. API bootstrap example • Boot akka-http server APIブートストラップの例

55. 〜Read-model updater〜 リードモデルアップデータ

56. リードモデルアップデータの設計 interface use-case infrastructure read-model use case ReadJournal (akka-persistence-query) dao,

    record port port(impl) port port(impl) Designing read-model updater(1/2) Read DB Write DB domain Domain Event

57. Designing read-model updater(2/2) • Sequentially read domain events per persistenceId(pid)

    to build read-models • Note: ◦ Should distribute the pid in charge if RMU num < pid num ◦ Should reassign pid responsible for the failed node to another node • This talk ignores the above issues, and shows a simple case as follows: ◦ 1 Domain Event Type : 1 RMU instance. リードモデルアップデータの設計 pid = 1 pid = 2 Aggregate1 Aggregate2 RMU record1 record2 Handle specific domain event type Write DB Read DB

58. Tagging events • Implement WriteEventAdaptor • add ADT name as

    tag to Event • The following settings are required イベントのタグ付け

59. Read-model use case example(1/2) • `execute` method executes an endless

    stream • `bankAccountReadModelFlows` and `journalReader` are ports for reading • First, the latest sequence number is obtained from the DB, consume the events using the tag name • In `projectionFlow`, the read-model is updated based on the domain events リードモデル用ユースケースの例

60. Read-model use case example(2/2) • `projectionFlow` builds read-models by receiving

    the domain events and sequence number. • Delegate the I/O resposibility to BankAccountReadModelFlows リードモデル用ユースケースの例

61. Read-model updater bootstrap example • Call BankAccountReadModelUseCase#execute リードモデルアップデータのブートスラップの例

62. Conclusion • Introduction of Reactive-DDD implementation example using Akka •

    The main tools used are as follows: ◦ akka-actor, akka-persistence, akka-cluster-sharding, akka-stream, akka-http • Reactive-DDD gets a advantage as compared to non Reactive-DDD, because it benefits both reflection of domain knowledge into code and non-functional requirements. • This book is recommended to learn the basics of Akka. まとめ

63. Thank you for listening! ご静聴ありがとうございました。

64. We’re Hiring!! http://corp.chatwork.com/ja/recruit/