Explores usage of JOliver EventStore project as event store implementation in CQRS solution

1. CQRS
with
JOliver Event Storev3

2. Об авторе

3. • 22 countries
• 20 banks integrations
• 80,000 financial administrations
• 50,000 users
• 51% of Dutch market
• Own data center
• 3500 concurrent users
• > 100 TPS

4. Дорога к CQRS

5. GUI
Database
access
Business
logicGUI
Database access
Business logic
GUI
GUI
Database access
GUI
Database access
Business logic
GUI
GUI Database
accessBusiness logic
GUI
Business
logic
Business logicGUI
Database access

6. GUI
Business
logic
Data
access

7. M$$SQL
GUI
Domain Model
ORM
Database

8. M$$SQL
GUI
Domain Model
ORM
Database
Lazy Loading !!!
OUCH!

9. M$$SQL
GUI
Domain Model
ORM
Database
DTO

10. M$$SQL
GUI
Domain Model
ORM
Database
DTO
Object-To-Object Mapping !!!
OUCH!

11. RDB
ORM
Отчеты
Domain
8-ми этажный SQL

12. А ручки то, на что?

13. RDB
Ручками
Отчеты
N этажный SQL
(правда, почище и побыстрее, чем с ORM)
SQL красиво упрятан за
фасадом хранимых
процедур 

14. RDB
DTO
Handcrafted SQL
ORM
Application
Services
Domain
Object
Domain
Object
Reporting
Services
3NF with optimizations
like 1NF in some places 
DTO DTO DTO
Form UI Reports UI
send
request

15. RDB
DTO
Handcrafted SQL
ORM
Application
Services
Domain
Object
Reporting
Services
DTO DTO DTO
Form UI Reports UI
Здесь
жирненько

16. И что дальше?

17. Data Storage
Command
Application
Services
Domain
Object
Query
Services
Client
Domain
Object
Query
Data Storage
DTO DTO
CQRS (did you mean “Cars”?)

18. Domain Model View Model
Как синхронизировать ?

19. ORMDomain Changeset Denormalizer
View Model
Потеря «сути» изменений
Непрозрачный сгусток
данных 

20. CQRS
+
Event Sourcing
=
LOVE!

21. ORMDomain
Storage
Текущее состояние
Традиционный подход

22. Domain Invoice
Created
Invoice
Approved
Invoice
Finalized
Журнал всех изменений
Event Sourcing

23. Традиционный подход

24. Event Sourcing

25. SRP на уровне метода !
Принятие решения о
возможности перехода
состояния
(бизнес-правила)
Переход состояния
(транзитор)
Собственно,
изменение состояния
(аппликатор)

26. И как это работает?
Ну и как это всё работает?

27. Восстановление текущего состояния
Invoice
Created
Invoice
Approved
Invoice
Finalized
Журнал изменений
1
2
3

28. Сохранение изменений
Invoice
Approved
Invoice
Finalized
Буфер

29. Сохранение изменений
Invoice
Approved
Invoice
Finalized
Буфер
Invoice
Created
Журнал изменений
1
append
2
Invoice
Approved
Invoice
Finalized3

30. Log.append(id, events)
events = Log.read(id)
Тривиально,
неправда ли?

31. Обеспечение параллельного доступа

32. Параллельные модификации
Invoice
Created
Invoice
Updated
Invoice
Finalized
update
Invoice
finalize

33. Оптимистическая блокировка
Invoice
Created
Stream
[ID:542]
1
Invoice
Created
Invoice
[ID:542]
1
load Invoice
Created
Invoice
[ID:542]
1
load
1

34. Оптимистическая блокировка
Invoice
Created
Stream
[ID:542]
1
2
Invoice
Finalized
load Invoice
Created
Invoice
[ID:542]
1
2 Invoice
Finalized
load
store
1
2
originalRevision = currentRevison
Invoice
Created
Invoice
[ID:542]
1

35. Оптимистическая блокировка
Invoice
Created
Stream
[ID:542]
1
2
Invoice
Finalized
22
Invoice
Updated
load
store
Invoice
Created
Invoice
[ID:542]
1
2 Invoice
Finalized
load
store
1
2
Invoice
Created
Invoice
[ID:542]
1
originalRevision != currentRevison

36. Допустимые параллельные модификации
Transaction
Posted
Transaction
Posted
Transaction
Posted
post
General Ledger
post
Трекать ревизию
аггрегата недостаточно


37. Высокая производительность

38. Минимальное количество
операций записи
E1
Aggregate Stream
Commit
E1 E1
pack
C1
serialize

39. Минимальное количество
операций записи
Commit
E1
Aggregate
E2
E3
E2
E3
Stream
C2
E2
E3
Commit
E1 E1
pack
pack
C1
serialize
serialize

40. Гибкие возможности сериализации
• JSON
• Binary
• Custom (ProtoBuf, .NET, whatever)
• GZip
• Криптование

41. Оптимизация операции восстановления
состояния при помощи «снимков»
Аггрегат с очень
длинным
жизненным
циклом и кучей
ивентов
E1
E2
…
E100500
Snapshot
[rev: E100500]
E100501
restore
replay the rest
of events

42. Распределенная транзакция
С1 С2 .. Сn
Command Queue
Command Processor
Event Store
dequeue (C1)
store (E1, E2)
MSDTC

43. Без 2PC
С1 С2 .. Сn
Command Queue
Command Processor
Event Store
0. peek (C1)
1. store (E1, E2)
2. remove (C1) T2
T1

44. Без 2PC необходима
поддержка идемпотентности
С1 С2 .. Сn
Command Queue
Command Processor
Event Store
0. peek (C1)
1. store (С1, [E1, E2]) 2. dup (С1)
4. remove (С1)
Commit
E1
E2

45. Без 2PC необходима
поддержка идемпотентности
С1 С2 .. Сn
Command Queue
Command Processor
Event Store
0. peek (C1)
1. store (С1, [E1, E2]) 2. dup (С1)
4. remove (С1)
Commit
E1
E2
ID : UUID

46. Без 2PC необходима
поддержка идемпотентности
С1 С2 .. Сn
Command Queue
Command Processor
Event Store
0. peek (C1)
1. store (С1, [E1, E2]) 2. dup (С1)
4. remove (С1)
Commit
E1
E2
ID : UUID
Command
ID : UUID

47. Обработка событий
Event Store View Model
E1 E2
publish update
2PC, опять?

48. Обработка событий (PULL)
Event Store View Model
Get new events since (Time)
Запоминать последнее
обработанное событие

49. Обработка событий (PULL)
Event Store View Model
Get new events since (Time)
Commit
E1
E2
ID : UUID

50. Обработка событий (PULL)
Event Store View Model
Get new events since (Time)
Commit
E1
E2
ID : UUID
Dispatched : bool

51. Обработка событий (PULL)
Event Store View Model
Get undispatched events
Commit
E1
E2
ID : UUID
Dispatched : bool
mark as
dispatched

52. Обработка событий (PUSH)
Event Store View Model
publish (commit)
Commit
E1
E2
ID : UUID
Dispatched : bool
Идемпотентность во
View Model хранилище
по-прежнему нужна 
mark as
dispatched

53. Встроенный диспетчер событий
BUS
Command
Processor
Event Store
cmd
events
commit Dispatcher
Event
Publisher
commit
events
Storage
Your App
commit
mark as dispatched
OK

54. Встроенный диспетчер событий
BUS
Command
Processor
Event Store
cmd
events
commit Dispatcher
Event
Publisher
commit
events
Storage
Your App
commit dispatched = false
FAIL

55. Архитектура

56. Commit
Event Store
Persistence Engine
Event Stream Commit
Event Message
Dispatcher
Storage

57. Поддерживаемые технологии
хранилища данных
Relational Databases:
• SQL Server 2005 (or later)
• MySQL
• Firebird
• Oracle (planned)
Embedded Relational Databases:
• SQL Server CE 3.5 (or later)
• SQLite 3.0 (or later)
• MS Access 2000 (or later)
Cloud-based Databases:
• MS SQL Azure
• Amazon RDS (MySQL)
• Azure Tables/Blobs (in progress)
• Amazon SimpleDB/S3 (in progress)
Document Databases
• RavenDB r322 (or later)
• MongoDB 1.6 (or later)
• CouchDB 1.0 (planned)

58. Расширяемость

59. Метаданые
Commit
Event Message
Dictionary<string, object>
Dictionary<string, object>
Office, User, PrecedingMessageId
EventId, AggregateType

60. Хуки
Event Store
Persistence Engine
Commit
Место для “врезки” в
конвейер обработки
Hook into:
• select
• pre-commit
• post-commit

61. Хуки

62. Диспатчер – это встроенный хук

63. Механизмы эволюции
схемы событий

64. 2 подхода
• Толерантный сериализатор
• Явное версионирование

65. Свалка аппликаторов в бизнес-аггрегате

66. Преемственность версий
InvoiceCreated
InvoiceCreated_v2
InvoiceCreated_v3
convert to
convert to

67. Хук-конвертер в Event Store

68. Проект CommonDomain

69. Базовый класс для Аггрегатов

70. Репозиторий - DAO для Аггрегатов

71. Обработка конфликтов параллельного доступа

72. Допустимые параллельные модификации
Transaction
Posted
Transaction
Posted
Transaction
Posted
post
General Ledger
post

73. Легко создавать специализированные политики
определения конфликтов параллельных изменений

74. Ссылочки:
• http://cqrs.wordpress.com
• https://github.com/joliver/EventStore
• https://github.com/joliver/CommonDomain