Design | expose ap is with cqr
Download as PPTX, PDF0 likes32 views
The document discusses modeling processes for exposing APIs using CQR and event sourcing principles. It describes identifying system entities and steps, defining and validating models through testing and documentation, and creating relationships between resources. Event sourcing principles are explained, including capturing all state changes as event objects stored sequentially. The benefits are traceability, easy undo, and after-the-fact analysis, while challenges include complexity, scalability, security and performance. CQRS segregates read and write operations using separate interfaces to maximize performance and scalability.
Design | expose ap is with cqr
- 1. Design | Expose APIs with CQR Quick Recap
- 2. Modeling Process ● Identification ○ Who (peoples, entities )use it ? ○ When they are going to do ? ○ External or internal ? ● Break into steps ● Definition ● Validation ○ Test ○ Document ● Creation ○ Find resources ○ Relation between resources
- 3. Verbs and Nouns If you want to dining out at nice places that you have to call ahead to reserve a table
- 4. What are the problem ? Principles :)
- 5. Principles ● Separation of concerns ● Reusable components ● DRY ● KISS ● SOLID ● … BTW, everything comes at a price !
- 6. Complexity comes to table ● Scalability ● Availability ● Security ● Performance ● … ● .... ● Representation(the same data using multiple models, ...)
- 7. Representation Most important part of a business is the state of the data. ● Decisions ● Roadmap ● Application functionality ● User experience ● ….
- 8. Taking care of state ? How ?
- 9. Event Sourcing ● Capture all changes to an application state as a sequence of events The fundamental idea of Event Sourcing is that of ensuring every change to the state of an application is captured in an event object, and that these event objects are themselves stored in the sequence they were applied for the same lifetime as the application state itself. https://martinfowler.com/eaaDev/EventSourcing.html
- 10. Event sourcing Pros (continued) ● Bypass the O-R impedance mismatch ● Easy way to undo things ● Debuggability and traceability a. Every change to state is traceable b. You know how the system got into the current state c. Metadata like "who did that" and "when did it happen" ● After-the-fact data analysis of Event Streams ● Awesome for writing data https://en.wikipedia.org/wiki/Object-relational_impedance_mismatch
- 11. Event sourcing Cons (continued) ● Takes getting used to ● Much less framework/community/vendor support ● Awkward queries (solved by CQRS) (terrible for reading)
- 12. Should I be doing Event Sourcing? ● you're building rich object-oriented domain models (e.g. DDD) ● you have a lot of behaviour that isn't CRUD ● accountability/debuggability is critical ● you need version control/undo for data (e. G. Wikis, Google Docs) ● your business derives value or competitive advantage from event data ● your domain is inherently event driven (e. G. football game tracking) ● you're building a scalable system based on the CQRS pattern
- 13. CQRS (Command Query Responsibility Segregation) Segregate operations that read data from operations that update data by using separate interfaces. This can maximize performance, scalability, and security. If the problem is having multiple and disparate views, we can exclude them from the Domain Model and start treating them as a purely infrastructural concern https://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs
- 15. Pros ● Your system should display its entities in different representation models. ● You have to support different querying models (search, graph, documents, etc.). ● The difference between writes and reads differs greatly, and you want to scale them independently. Cons ● Eventual consistency (make persistence transactional) ● Still complex fellow ● Complex Monitoring and infrastructure
- 17. Concepts ● Event Stream ● Event Store ● Snapshot Store ● Projection ● Service Bus
- 18. Example