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.

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