CQRS

 


Stack doesn't follow CQS as it both deletes and reads at the same time.

FileExists on left can become stale as file may be deleted after FileExists is called.  Code on right is safer method however it doesn't follow CQS.




Scalability 
Always far more Reads than writes, so the separation allows you to scale both independently.  For instance you could have 1 server for all writes and 10 servers for all reads.


Performance
You can add in customised performance enhancements to the read side such as caching and highly optimised queries.

Simplicity
Rather than have one model that is trying to account for reading and writing, CQRS allows you to have one optimised for the specific task of reading or writing.  Allows you to make different decisions for reads and writes. We've only model that does one thing well.

CQRS solves a lot of problems with CRUD based interface.


How many features are in this UI?

The solution to solve a CRUD based interface is a Task based interface.


Example of an Edit personal info which replaces update








Optional: no need to specify event, command and query if follow above guidelines.






Commands and DTOs solve different problems.


Without DTOs, our API will introduce breaking changes with every change of the domain model or will not be able to properly evolve the domain model because of the constraints imposed by the backward compatibility.   Choosing both commands and DTOs and the mapping between them means the application will be both backward compatible and easy to refactor. 





Ok to implement parts of a pattern that make sense.





Need to return an OK that command has been successful and it is fine to return an ID as this is a type of locator.  No point in over complicating the code just for a principle. 


Classic example of the contradiction between the DRY principle and the principle of loose coupling.  Loose coupling wins in the vast majority of cases other than the simplest of ones.





Comments

Post a Comment

Popular posts from this blog

Microservices and Service-Oriented Architecture

  Microservices Architecture and Service-Oriented Architecture (SOA) , along with their similarities, differences, and typical use cases. Microservices Architecture Microservices is an architectural style where applications are composed of small, independent services that communicate over a network. Each service is typically designed around a specific business function and operates as an isolated, self-contained unit. Here are some key characteristics: Independently Deployable : Each service can be developed, deployed, and scaled independently of others. Single Responsibility : Services are organized around business capabilities, such as “Order Processing” or “User Authentication.” Resilience : Each microservice operates independently, making the system more resilient since failures in one service do not necessarily impact others. Polyglot Persistence and Programming : Microservices allow for diverse technologies, frameworks, and databases across services, optimizing each service...
Read more

Version control and Continuous Integration/Continuous Deployment (CI/CD)

 Version control and Continuous Integration/Continuous Deployment (CI/CD) are fundamental practices in modern software development that enhance collaboration, maintainability, and quality of software projects. Below, we’ll explore each concept, including their principles, benefits, and key practices. Version Control Version Control is a system that records changes to files or sets of files over time, allowing developers to track and manage changes to their codebase. It facilitates collaboration among team members and provides a history of changes, making it easier to revert to previous versions if needed. Key Principles of Version Control Track Changes : Every change made to the codebase is recorded, allowing developers to see who made changes, what changes were made, and when. Branching and Merging : Developers can create branches to work on features or fixes in isolation without affecting the main codebase (usually referred to as the main or master branch). Once the work is co...
Read more

Principles of Clean Code

  Clean Code refers to a set of coding practices and principles aimed at writing code that is easy to read, understand, and maintain. The concept was popularized by Robert C. Martin in his book Clean Code: A Handbook of Agile Software Craftsmanship . Here are the key principles of Clean Code: 1. Readability Clear Naming : Use descriptive and meaningful names for variables, functions, classes, and other entities. Names should convey intent and be easily understandable. Consistent Formatting : Maintain consistent indentation, spacing, and formatting to improve the readability of the code. Use conventions that are standard in the programming community. Logical Structure : Organize code logically, grouping related functionality together and following a consistent structure. 2. Simplicity KISS (Keep It Simple, Stupid) : Strive for simplicity in design and implementation. Avoid unnecessary complexity and over-engineering. Each component should do one thing well. YAGNI (You Aren't Gonna ...
Read more