Command query segregation principle
Upcoming SlideShare
Loading in...5
×
 

Command query segregation principle

on

  • 673 views

 

Statistics

Views

Total Views
673
Views on SlideShare
673
Embed Views
0

Actions

Likes
1
Downloads
7
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Think different\nA different take on things\nAnalogy to iphone, no buttons\n
  • Things will be a bit different, don’t dismiss it right away\n
  • \n
  • All data in paper form\n
  • Using them for data entry\n
  • Trying to remove the need for cabinets\nUI. designed for this purpose\nMake data entry efficient\n
  • Type tab, type tab\nThe paper was the source of truth\n
  • All data in the machine\nNew data was created directly in the machine\nShift in power\nValidation was suddenly needed\nUsers acted on the behalf of the users\n
  • Not data entry any more\nNo external source of truth\nSystems are collaborative\nValidation came -> need to protect data\n
  • Using the same architecture as before\nOO came around when data was king\nLayered design as well\n
  • \n
  • These are good ideas\nMore might be needed?\nUsers are missing from all the pictures\n
  • The balance of power has shifted\n\n
  • Making decisions in parallel and on stale data\nCan’t fight gravity\n
  • Do we have to do all this to show stale data?\nPerformance intensive, add cache\nCaches is also stale data\nSo: We’re using data entry ui:s to show people stale data\n
  • Doing alot of work again to show stale data\nMore caching\n\n
  • What was the point of all this again?\nWas was the reason?\nMaintainability? a lot of code\nPerformance?\nScalable?\nThere is something missing\n\n
  • One step back\nLets solve one thing at a time\nData becomes stale right away\nBe upfront about how stale data is\n\n
  • Queries are data only?\nNo behaviour\nTherefor not an object\nAggregated data is needed to support the users\n
  • Queries are data only?\nNo behaviour\nTherefor not an object\nAggregated data is needed to support the users\n
  • The agile way\nDon’t kill me know\nStored in same for as the users want to see it\nselect * from table where ...\nNo ORM, DDD, EF, SOA, DTO , ESB , xyz\nStorage is cheap\n
  • How does the storage look like\nIndex is needed yes\nReferential integrity is not needed for stale data\nData duplication is fine for stale data\n
  • Amazon example\nMongo db scale out example\n
  • All data is accessible\nGmail, yahoo signup example\nKeep the stale data close to the users to make it fast\n“Decision support system”, proactive!\nSimple, scalable, maintainable, performant...\n
  • Remember, no paper!\nMaking decision based on stale data\nWe need to protect our data from the users\nWell behaved clients will have prevalidated the data\n
  • Validation can be performed without additional data\nIe performed on the command itself\nRules need up to date data!\nWhat is the user asking us to do based on the data in our DB\n
  • \n
  • Validation is a component that can be used both client and server side\nThe command will always succeed\nThank you, well let you know by email\nDo we need an a response right away?\nEverything server side is done in one transaction\nDesigning the system using the fact that commands succeed\n
  • Validation is a component that can be used both client and server side\nThe command will always succeed\nThank you, well let you know by email\nDo we need an a response right away?\nEverything server side is done in one transaction\nDesigning the system using the fact that commands succeed\n
  • Validation is a component that can be used both client and server side\nThe command will always succeed\nThank you, well let you know by email\nDo we need an a response right away?\nEverything server side is done in one transaction\nDesigning the system using the fact that commands succeed\n
  • Validation is a component that can be used both client and server side\nThe command will always succeed\nThank you, well let you know by email\nDo we need an a response right away?\nEverything server side is done in one transaction\nDesigning the system using the fact that commands succeed\n
  • Validation is a component that can be used both client and server side\nThe command will always succeed\nThank you, well let you know by email\nDo we need an a response right away?\nEverything server side is done in one transaction\nDesigning the system using the fact that commands succeed\n
  • Validation is a component that can be used both client and server side\nThe command will always succeed\nThank you, well let you know by email\nDo we need an a response right away?\nEverything server side is done in one transaction\nDesigning the system using the fact that commands succeed\n
  • Validation is a component that can be used both client and server side\nThe command will always succeed\nThank you, well let you know by email\nDo we need an a response right away?\nEverything server side is done in one transaction\nDesigning the system using the fact that commands succeed\n
  • Commands = this is what I would have liked to happen, user intent\nShould entities then be the center piece of our architecture\nOOAD is not that important\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Ui:s are mashups /composite apps\nScaling write side independent of write side\nCode is smaller and more focused\nEasier to do UI screens now that data maps 1 to1\nDomain models is smaller given that they only process commands\nMore moving parts but all parts is very simple and loosely coupled\n\n
  • Ui:s are mashups /composite apps\nScaling write side independent of write side\nCode is smaller and more focused\nEasier to do UI screens now that data maps 1 to1\nDomain models is smaller given that they only process commands\nMore moving parts but all parts is very simple and loosely coupled\n\n
  • Ui:s are mashups /composite apps\nScaling write side independent of write side\nCode is smaller and more focused\nEasier to do UI screens now that data maps 1 to1\nDomain models is smaller given that they only process commands\nMore moving parts but all parts is very simple and loosely coupled\n\n
  • Ui:s are mashups /composite apps\nScaling write side independent of write side\nCode is smaller and more focused\nEasier to do UI screens now that data maps 1 to1\nDomain models is smaller given that they only process commands\nMore moving parts but all parts is very simple and loosely coupled\n\n
  • \n
  • \n
  • Scalability is determined by the write side\n
  • \n
  • \n
  • \n
  • \n

Command query segregation principle Command query segregation principle Presentation Transcript