Upload
msdevmtl
View
328
Download
0
Embed Size (px)
Citation preview
© P
yxis
Tec
hnol
ogie
s in
c.
ARCHITECTURE MUST COMMUNICATE MAJOR
IMMUTABLE DESIGN DECISION VIA UNDERSTANDABLE
ABSTRACTIONS
© P
yxis
Tec
hnol
ogie
s in
c.
12
Database
Business logic
CLIENT/SERVER APPLICATION
User interface
Database
Business logic
User interface
© P
yxis
Tec
hnol
ogie
s in
c.
13
User interface
Database
Business logic
N-TIER APPLICATION
User interface
Database
Business logic
Database
Business logic
User interface
© P
yxis
Tec
hnol
ogie
s in
c.
14
User interface
Database
Business logic
TYPICAL ARCHITECTURE
User interface
Database
Business Logic
Database
Business logic
User interface
© P
yxis
Tec
hnol
ogie
s in
c.
Each layer depends on another layerUsually all layers depends on the same infrastructure
layerUI is tightly coupled with the database (read and write)
Data layer objects often leak all the to UIData structure has big side effect on domain and UISingle 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
© P
yxis
Tec
hnol
ogie
s in
c.
Doesn't easily allow Domain Driven Design (DDD) concept
Usually works with CRUDThis reflect to the UI when a user must know the
data structure to make changesThe system doesn't capture user intentionHow to implement…
Auditing / Logging / Traceability?Reporting?Distributed data?
DATA DRIVEN ARCHITECTURE
© P
yxis
Tec
hnol
ogie
s in
c.
EVOLUTION…?
EACH CHANGE TAKE EXPONENTIALLY
MORE TIME THAN THE PREVIOUS
© P
yxis
Tec
hnol
ogie
s in
c.
CAP THEOREM IN DISTRIBUTED SYSTEM
Availability
PartitioningConsistency
A
C P
CA AP
CP
SQL ServerOracle
MongoDBRedis
CassandraCouchDB
CAN'T HAVE ALL 3 AT THE SAME TIME
© P
yxis
Tec
hnol
ogie
s in
c.
22
UI DataBusiness
Request
Command Write
Read
TYPICAL APPLICATION
OPTIMIZE READ WITH INDEXES
INDEXES AS NEGATIVE PERFORMANCE ON WRITES
CAN'T OPTIMIZE READ AND
WRITE ON THE SAME DATABASE
© P
yxis
Tec
hnol
ogie
s in
c.
23
UI DataBusiness
Request
Command Write
Read
WORKING WITH STALE DATA
20ms 100ms
20ms 100ms
100ms
20ms
Approx. 360ms. + User thinking
1000+ ms.
DATA ARE ALWAYS STALE
© P
yxis
Tec
hnol
ogie
s in
c.
HOW TO BUILD PERFORMANT (DISTRIBUTED) SYSTEM THAT
TAKE ACCOUNT STALE DATA AND IS EASY TO MAINTAIN AND
EVOLVE?
© P
yxis
Tec
hnol
ogie
s in
c.
Domain ObjectsEntityValue objectAggregate (root)
InfrastructureServiceRepositoryFactory
DDD TERMINOLOGY
© P
yxis
Tec
hnol
ogie
s in
c.
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
© P
yxis
Tec
hnol
ogie
s in
c.
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
© P
yxis
Tec
hnol
ogie
s in
c.
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)
© P
yxis
Tec
hnol
ogie
s in
c.
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
© P
yxis
Tec
hnol
ogie
s in
c.
A (DOMAIN) REPOSITORY ACT AS AN ABSTRACTION BETWEEN AN AGGREGATE AND ITS PERSISTENCE. IT TAKE CARE OF
RECREATING AN INSTANCE FROM ONE OR MANY PERSISTENCE SOURCES.
REPOSITORY
© P
yxis
Tec
hnol
ogie
s in
c.
A FACTORY ONLY CREATE OBJECT IN A CONSISTENT STATE WITH ALL INVARIANTS
SATISFIED. THIS CONSTRUCTION SHOULD BE AN ATOMIC PROCESS.
FACTORY
© P
yxis
Tec
hnol
ogie
s in
c.
32
SEPARATE READ FROM WRITE
UI Write model
DomainCommand Write
Commands - change data
UI Read model
QueryRequest Read
Queries - read data (no side effect)
© P
yxis
Tec
hnol
ogie
s in
c.
33
WE NEED TO SYNCHRONIZE WRITE AND READ MODELS
UI Write model
DomainCommand Write
Commands - change data
UI Read model
QueryRequest Read
Queries - read data (no side effect)
© P
yxis
Tec
hnol
ogie
s in
c.
DEFINE SOMETHING THAT HAPPENED IN THE PASS. IT IS IMMUTABLE. IT
MUTATE THE STATE OF AN AGGREGATE AND KEEP IT COHERENT.
IT IS SEQUENTIAL AND SERIALIZABLE.
DOMAIN EVENT
© P
yxis
Tec
hnol
ogie
s in
c.
Invite the right people People that know the questions People that know the answers
Provide unlimited modeling spaceExplore 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
© P
yxis
Tec
hnol
ogie
s in
c.
EVENT SOURCING
AGGREGATE
OrderCreated
ProductAdded
ProductAdded
ProductRemove
dProductAdded
OrderComplet
ed
AN AGGREGATE HOLDS HIS OWN DOMAIN EVENTS AND BUILD ITS STATE FROM THEM
© P
yxis
Tec
hnol
ogie
s in
c.
MANY PERSPECTIVES ON DATA
Customer
Product
CostMarkup
Quantity
PriceQuantity OrderedName
Buyers InventoryManager
SalesRep.
© P
yxis
Tec
hnol
ogie
s in
c.
MANY PERSPECTIVES ON DATA
Buyers InventoryManager
Product
Quantity
ProductId
Product
CostMakup
ProductId
Product
PriceQuantity OrderedName
ProductId
Shared Entity Identity
SalesRep.
Bounded Context
© P
yxis
Tec
hnol
ogie
s in
c.
PUTTING IT ALL TOGETHER
Client
Commands CommandBus
Sends
Command Handlers
Modify
Repositories
Read Write
Datastore
EventBus
Publish Events
EventBus
Command Services
Event HandlersEvents
Denormalized
Read storeQuery
Facade
Query HandlersQuery Results
Queries
Query Services
Events
Domain
UI
adaptation from Jeppe Cramon
© P
yxis
Tec
hnol
ogie
s in
c.
DO NOT DESIGN FOR LOCALITY AND TRY TO DISTRIBUTE
DESIGN FOR DISTRIBUTION, TAKE ADVANTAGE OF LOCALITY
© P
yxis
Tec
hnol
ogie
s in
c.
DO START WITH SYNCHRONOUS CALLS AND TRY TO MAKE THEM
ASYNCHRONOUS
START WITH ASYNCHRONOUS CALLS AND SYNCHRONIZE THE RESPONSES