Cqrs in babysteps

Jun 16, 2014Download as PPTX, PDF3 likes6,883 views

This document discusses Command Query Responsibility Segregation (CQRS). CQRS separates commands and queries in an application by using different models for reading and writing data. This improves separation of concerns and allows for greater scalability. While CQRS requires upfront work to set up the infrastructure, it results in simpler domain models and a complete rebuild of application state is possible through event sourcing. The document provides examples of how to implement CQRS and addresses some common misconceptions.

Command Query Responsibility
Segregation
In Babysteps
@talboomerik

Founder of Software craftsmanship guild Belgium
@talboomerik

Thanks to
@yreynhout @alastairs
@sandromancuso @adibolb

WHERE DID IT COME FROM?
A little history
@talboomerik

Command and Query Separation
It states that every method should either be a
command that performs an action, or a query that
returns data to the caller, but not both. In other
words, asking a question should not change the
answer. More formally, methods should return a
value only if they are referentially transparent and
hence possess no side effects.
Wikipedia - Bertrand Meyer
@talboomerik

IF YOU HAVE A RETURN TYPE, YOU
SHOULD NOT CHANGE STATE
Query
@talboomerik

IF YOU CHANGE STATE YOUR
RETURN TYPE SHOULD BE VOID
Command
@talboomerik

BASICALLY CQRS IS CQS SPLIT IN
DIFFERENT OBJECTS
The simple definition
@talboomerik

QUERY OBJECTS OVER QUERY
SERVICES / REPOSITORIES
http://lostechies.com/jimmybogard/2012/10/08/favor-query-objects-over-repositories/
@talboomerik

WHAT IS THIS ALL ABOUT?
What��s the fuss
@talboomerik

YOUR TYPICAL N-TIER
ARCHITECTURE
@talboomerik

http://codeofrob.com/entries/cqrs-is-too-complicated.html

REMOVING QUERIES FROM YOUR
DOMAIN MODEL
@talboomerik
@sandromancuso

LET��S TAKE IT ONE STEP FURTHER
If needed
@talboomerik

OR EVEN FURTHER
If applicable
@talboomerik

HOW TO SYNCHRONIZE
READ/WRITE?
@talboomerik

DOMAIN EVENTS
A cool pattern
@talboomerik

LET��S HAVE A LOOK AT SOME CODE
@talboomerik

TAKING IT TO ANOTHER LEVEL
Event sourcing
@talboomerik

FOCUSING ON BEHAVIOR INSTEAD
OF STATE
@talboomerik

SOME MISCONCEPTIONS ABOUT
CQRS
@talboomerik

CQRS <> DDD
It��s not the same
@talboomerik

CQRS <> EVENT SOURCING
They just go well together
http://lostechies.com/jimmybogard/2012/08/22/busting-some-cqrs-myths/
@talboomerik

CQRS CAN HAVE AN IMMEDIATE
CONSISTENT READ STORE
http://lostechies.com/jimmybogard/2012/08/22/busting-some-cqrs-myths/
@talboomerik

CQRS DOES NOT FORCE YOU TO USE
A BUS
http://lostechies.com/jimmybogard/2012/08/22/busting-some-cqrs-myths/
@talboomerik

COMMANDS DO NOT NEED TO BE
FIRE-AND-FORGET
Accepting the request vs Fulfilling the request
http://lostechies.com/jimmybogard/2012/08/22/busting-some-cqrs-myths/
@talboomerik

WHY IS THIS A GOOD IDEA?
Pros and cons
@talboomerik

SIMPLER DOMAIN MODEL
By splitting
@talboomerik

BETTER SEPARATION OF CONCERNS
AND RESPONSIBILITIES
@talboomerik

SCALABILITY
Technical and team
@talboomerik

COMPLETE REBUILD OF THE
APPLICATION STATE THROUGH EVENT
SOURCING
http://martinfowler.com/eaaDev/EventSourcing.html
@talboomerik

TEMPORAL QUERYING
Replay history
http://martinfowler.com/eaaDev/EventSourcing.html
@talboomerik

AUDIT LOG
I see you
http://martinfowler.com/eaaDev/EventSourcing.html
@talboomerik

IT DOES REQUIRE ��SOME�� WORK
UPFRONT
Set up infrastructure
@talboomerik

IT WORKS BEST WITH TASK-BASED
UI
Delivery mechanism and domain architecture need to collaborate

IT IS NOT EASY
It��s a big shift from what we are used to
@talboomerik

HOW CAN WE GET THIS DONE?
Code, show us code
@talboomerik

THANK YOU
That��s all folks
@talboomerik

The way IT change economy, work and the world is growing and impactful, and we just start to think about our process as IT workers. What is our role? Why developer efficiency is really important? How about deliverability velocity? This talk is focus on process, tools and organisation around the software delivery and focus about the infrastructure role. The goal is to give insight about architecture choices, arguments to promote projects and investments to the management, transitional vision and traditional IT integration.

HTTP/2 : why upgrading the web? - DjangoCon Europe 2016 BudapestQuentin Adam

Refactoring Legacy Code - true storyAki Salmi

The document discusses refactoring legacy code for a client project. It describes steps taken to refactor code for searching products and handling file attachments. For searching, the speaker extracted parameters from a method with 21 parameters and 200 lines of code into a builder pattern. For attachments, switch statements were replaced with polymorphism, and file processing logic was extracted from a service into separate classes. The refactoring was done incrementally using test-driven development practices learned at coderetreats. Tests were added to verify changes at each step, and over 30 commits were made. The refactoring provided value to customers while improving code quality and maintainability.

Tom Gilb - Power to the Programmers @ I T.A.K.E. Unconference 2014, BucharestMozaic Works

Leading Tech TeamsFlavius Stef

Crafted Design - ITAKE 2014Sandro Mancuso

(IMPROVED VERSION FROM GEECON) How can we quickly tell what an application is about? How can we quickly tell what it does? How can we distinguish business concepts from architecture clutter? How can we quickly find the code we want to change? How can we instinctively know where to add code for new features? Purely looking at unit tests is either not possible or too painful. Looking at higher-level tests can take a long time and still not give us the answers we need. For years, we have all struggled to design and structure projects that reflect the business domain. In this talk Sandro will be sharing how he designed the last application he worked on, twisting a few concepts from Domain-Driven Design, properly applying MVC, borrowing concepts from CQRS, and structuring packages in non-conventional ways. Sandro will also be touching on SOLID principles, Agile incremental design, modularisation, and testing. By iteratively modifying the project structure to better model the application requirements, he has come up with a design style that helps developers create maintainable and domain-oriented software.

Hands on continouous delivery, I TAKE 2014Ioan Eugen Stan

Putting the science in computer scienceFelienne Hermans

Programmers love science! At least, so they say. Because when it comes to the ��science�� of developing code, the most used tool is brutal debate. Vim versus emacs, static versus dynamic typing, Java versus C#, this can go on for hours at end. In this session, software engineering professor Felienne Hermans will present the latest research in software engineering that tries to understand and explain what programming methods, languages and tools are best suited for different types of development.

BDD with Cucumber-JVM as presented at I T.A.K.E. Unconference in Bucharest 2014TSundberg

Sandro Mancuso - Software Craftmanship @ I T.A.K.E. Unconference 2013, BucharestMozaic Works

1) Software Craftsmanship focuses on producing well-crafted, high-quality software through practices like automated testing, test-driven development, and pair programming. 2) It values not only working software and responding to change, but also steadily adding value and a community of skilled professionals. 3) Being a software craftsman requires continuously improving one's skills through practice and experience over many years to master the craft of software development.

Erik talboom - TDD as if The Baby Meant it @I T.A.K.E. Unconference 2013, Buc...Mozaic Works

Sandro Mancuso �C Testing and refactoring legacy code @ I T.A.K.E. Unconferenc...Mozaic Works

The document discusses refactoring legacy code for a social networking website for travelers. It describes business requirements where users must be logged in to see content and be friends to see others' trips. When refactoring production code, tests must be added first and refactoring should start from the deepest code branches and move outward. Tests should also be added from the shortest code branches outward. Tips are provided on writing clean, readable code and tests in small, safe increments with frequent commits while embracing changes.

Simplifying your design with higher-order functionsSamir Talwar

I T.A.K.E. talk: "When DDD meets FP, good things happen"Cyrille Martraire

Domain-Driven Design (DDD) and Functional Programming (FP) have a lot of good things in common: DDD has borrowed many ideas from the FP community, and both share a common inspiration on established formalisms like maths. For the software developer, the result is a style of code that mixes the best of DDD, OO and FP. Even in non functional languages like Java or C#, this combined set of practices helps craft simple and powerful code that reads well and that is very easy to test. In this talk we will have a closer look at some of these ideas, in the context of domain models inspired from real-world projects. From basic FP hygiene like immutability and closure of operations to more mathematical inspirations from abstract algebra like monoids, we will show how all that translates into beautiful code. WARNING: This may influence your coding style�� This talk was presented on the first day of I T.A.K.E. 2013 at Bucharest http://itakeunconf.com/

The Good the Bad and the Ugly of Dealing with Smelly Code (ITAKE Unconference)Radu Marinescu

We all have a burning desire to write clean code. Every morning we wake up, look in the mirror, and promise ourselves that today we will follow the principles and best practices learned from Uncle Bob and his disciples. But we live in a cruel environment, surrounded by millions of smelly lines of code, reflections of a stinky design�� and these constantly challenge our pure-hearted desire for writing clean code. In such an environment, the stubbornness to practice daily the writing of clean code is vital. But is it enough? Can we avoid getting lost in a sea of smelly code and design? In this talk I will try to persuade you that, in dealing with large-scale systems, craftsmanship must be supported by proper techniques and tools that can help us to quickly understand, assess and improve the sea of smelly design that surrounds us. I will present a pragmatic approach on how design anti-patterns (e.g. God Class, Feature Envy, Refused Bequest, Shotgun Surgery) can be automatically detected using a set of metrics-based detection rules, by analyzing the history of the system, and by using intriguing software visualizations. The presentation will also include a live demo of tools that can automate the entire approach to a high-extent. These tools are so robust that they can deal with systems of several million lines of code; but they are also friendly enough to provide you with customized hints that help you deal with each and every case of an ��unclean�� code.

Microservice Architecture with CQRS and Event SourcingBen Wilcock

This document provides an overview of microservice architecture using CQRS (Command Query Responsibility Segregation) and Event Sourcing patterns. It defines CQRS as separating the write and read functions of an application. Event Sourcing records all state changes as a series of events rather than just the current state. The benefits include scalability, simplicity, flexibility and a business focus. Popular companies using this architecture include those needing cost-effective scaling like microservices. The author provides resources and advocates for CQRS and Event Sourcing to solve common architectural challenges.

Domain Driven RailsYan Pritzker

The Worst Technical SEO Nightmares and How to Avoid ThemAleyda Sol��s

tweetchat-ledsCasey Meserve

The document discusses an online conversation about LED lighting trends. Participants discuss LEDs growing to 80% of the lighting market by 2020 due to decreasing costs and improving technology. Key points addressed include the importance of using LED-compatible dimmers, potential for other states to require LEDs in building codes like California has, and how color temperature is an important factor to consider for different rooms.

Contributing to WordPress CoreJeffrey Pearce

TDD That Was Easy!Kaizenko

�ݺ�ߣs from the session "TDD - That Was Easy!" presented by Fadi Stephan from Kaizenko at AgileDC2019 on September 23, 2019 in Washington DC. A blog post accompanying this talk will be published soon on kaizenko.com Abstract: Have you tried TDD? Do you hate it? Do you have a hard time applying it in practice? Do you find it promoting bad design decisions because you must write micro tests instead of looking at the big picture? Are your tests tightly coupled to the implementation due to a lot of mocking making refactoring a pain? Do tons of tests break when a simple change is made? Do you have a hard time justifying all the time spent on writing tests vs. just focusing on development? You are not alone. Every organization or team that I run into is supposedly Agile. Some are also applying agile engineering practices such as automated unit, integration and acceptance testing, etc�� However, many struggle with TDD. TDD is hard, seems counter-intuitive and requires a lot of investment. Come to this session for a TDD reboot. We will look at the benefits of TDD, discuss the resistance to TDD and uncover some common difficulties along with misconceptions. We will address these misunderstandings and explore different approaches to making TDD easier. Leave with a fresh perspective and new insights on how to become better at TDD and apply it with ease

Migrating existing monolith to serverless in 8 stepsYan Cui

The document discusses refactoring a monolithic application to a serverless architecture in 8 steps. It covers identifying service boundaries, organizing code into separate repositories for each service, choosing deployment tools, keeping functions simple and single-purpose, and migrating features to new services incrementally while maintaining compatibility with the existing monolith. The goal is to break the application into small, autonomous services that can be developed and deployed independently for improved scalability, resilience and development velocity.

Docker for devErik Talboom

Gamestorming (opnieuw) leren samen spelenErik Talboom

Why agile - ING bootcampErik Talboom

AgileTour2010 Belgium - Ghent: KeynoteErik Talboom

This document provides an overview of agile principles and practices. It includes the speaker's experience and passions, which involve agile training and coaching. The document outlines topics to be covered such as the agile manifesto, scrum, ALM, and why organizations adopt agile. Events and training related to agile, such as test-driven development and professional scrum developer courses, are also advertised.

AgileTour2010 Ghent KeynoteErik Talboom

Agile software developementErik Talboom

The document discusses agile software development principles and practices. It describes Erik Talboom's experience and passions, which include agile development, code quality, and training. The presentation covers agile concepts like the agile manifesto, collaboration over rules, adding business value, and continuous improvement. It also discusses specific agile practices like scrum, test-driven development, and software craftsmanship. Upcoming agile events in Belgium are also advertised.

The agile state of mindErik Talboom

Erik Talboom gave a presentation on the agile state of mind at Bizzcamp2010. He has 10 years of IT experience and is passionate about agile development practices. The presentation discussed what agile is not about (speeding up processes or micromanagement), what it is about (trust, collaboration and embracing change), why organizations should be agile (to better adapt to inevitable change), and how it could impact businesses in the future (improved customer satisfaction and working conditions through open communication). Talboom encouraged an open discussion and emphasized that he does not have all the answers.

The Future of Repair: Transparent and Incremental by Botond De?nesScyllaDB

Regularly run repairs are essential to keep clusters healthy, yet having a good repair schedule is more challenging than it should be. Repairs often take a long time, preventing running them often. This has an impact on data consistency and also limits the usefulness of the new repair based tombstone garbage collection. We want to address these challenges by making repairs incremental and allowing for automatic repair scheduling, without relying on external tools.

More Related Content

Viewers also liked (8)