Weitere ähnliche Inhalte Ähnlich wie How ddd, cqrs and event sourcing constitute the architecture of the future (20) Kürzlich hochgeladen (20) How ddd, cqrs and event sourcing constitute the architecture of the future14. ©PyxisTechnologiesinc.
Each layer depends on another layer
Usually all layers depends on the same infrastructure
layer
UI is tightly coupled with the database (read and write)
Data layer objects often leak all the to UI
Data structure has big side effect on domain and UI
Single point of failure (the single database)
After some time, system like that are too hard to
maintain and they become legacy and get rewritten
(Usually using the same architecture)
WHAT'S WRONG WITH
LAYERED ARCHITECTURE
17. ©PyxisTechnologiesinc.
Doesn't easily allow Domain Driven Design
(DDD) concept
Usually works with CRUD
This reflect to the UI when a user must know the
data structure to make changes
The system doesn't capture user intention
How to implement…
Auditing / Logging / Traceability?
Reporting?
Distributed data?
DATA DRIVEN ARCHITECTURE
25. ©PyxisTechnologiesinc.
AN ENTITY IS NOT DEFINED BY ITS
ATTRIBUTES. IT IS ONLY IDENTIFIYABLE BY A
UNIQUE IDENTITFIER. IT CAN EVOLVE
THROUGH TIME AND CAN BE ASSOCIATED
WITH OTHER OBJECTS
ENTITY
26. ©PyxisTechnologiesinc.
A VALUE OBJECT IS DEFINED BAY ALL ITS
ATTRIBUTES. IT CAN BE PASS ONLY BY
IMMUTABLE COPY OF ITSELF. ANY CHANGE
WOULD RESULT IN A NEW AND UNRELATED
OBJECT.
CONTEXT MATTER!
VALUE OBJECT
27. ©PyxisTechnologiesinc.
AN AGGREGATE IS A CLUSTER OF ENTITY
AND VALUE OBJECT THAT ARE CLOSELY
RELATED.
(ONE ENTITY IN THAT CLUSTER ACT AS A
ROOT OBJECT AND IS THE ONLY ONE THAT
CAN BE REFERENCED FROM THE OUTSIDE)
AGGREGATE (ROOT)
28. ©PyxisTechnologiesinc.
SERVICE IS A STATELESS OBJECT THAT USE
DOMAIN OBJECT AS INPUT AND OUTPUT.
SERVICE OPERATION SHOULD NOT BE
SOMETHING THAT BELONG TO ENTITY OR
VALUE OBJECT.
SERVICE
32. ©PyxisTechnologiesinc.
33
WE NEED TO SYNCHRONIZE
WRITE AND READ MODELS
UI Write
model
Domain
Command Write
Commands - change data
UI Read
model
Query
Request Read
Queries - read data (no side effect)
34. ©PyxisTechnologiesinc.
Invite the right people
People that know the questions
People that know the answers
Provide unlimited modeling space
Explore and define Domain Events
Relevant to business
Placed in order
Explore origin of Domain Events
User action are commands
Time may trigger some events
Group events in aggregates
Derive entities and value objects
EVENT STORMING
37. ©PyxisTechnologiesinc.
MANY PERSPECTIVES ON DATA
Buyers Inventory
Manager
Product
Quantity
ProductId
Product
Cost
Makup
ProductId
Product
Price
Quantity Ordered
Name
ProductId
Shared Entity Identity
Sales
Rep.
Bounded Context
38. ©PyxisTechnologiesinc.
PUTTING IT ALL TOGETHER
Client
Commands
Command
Bus
Sends
Command
Handlers
Modify
Repositories
Read Write
Data
store
Event
Bus
Command Services
Event Handlers
Events
Denormalized
Read
store
Query HandlersQuery Results
Queries
Query Services
Events
Domain
UI
adaptation from Jeppe Cramon
Hinweis der Redaktion Simple architecture: input, process, output. Partial online view. Rest of process delayed to batch. Client server applications Multi layered architecture Service based architecture Distrbuted system / cloud Does your current application look like this? Did you ever encounter this problem? Optimization is always a challenge Live data is an illusion event with reactive system. Phone number in the context of employee is a value object but not in a context of a cellphone company. Transactional context Solve the read and write optimization
The problem is do we synchronize the write and the read model Single data store is a bottle neck. Solves the evolution / complexity problem Demo