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
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
● ….
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
14.
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
