Add an eventSessions at GOTO Amsterdam 2011 about CQRS
Your current filters are…
- Topic: CQRS
Thursday 13th October 2011
-
Solution Track: Exploring light-weight event sourcing
Currently many business applications are developed using a very database centric approach, often requiring the use of complex and heavy-weight Object-Relational Mappers (ORMs) to make developers productive. Although improvements have been made (through the use of annotations, reflections, conventions) the core issues remain:
Lack of modularity
High coupling to the used ORM and/or underlying database, making it unnecessarily hard to use alternative (NoSQL) or multiple databases
Hard to understand the full application, due to the complexity of the used ORM
Mutability is in-grained, reducing the possibilities for composition and modularity
Limited possibility for abstraction, due to limitations imposed by the ORM on used data types, etc.
In this talk we'll explore the use of an alternative approach usingthe techniques pioneered by Domain-Driven Design (DDD) and especiallyCommand-Query Responsibility Segregation (CQRS): Event Sourcing.Using Event Sourcing the application can be split into two parts:
Domain logic responsible for generating events (command side)
Reporting, view, integration, etc. logic that consumes the generated events ("query" side).
Through this explicit notion of change (domain events) the developer is put back in control of the application.Traditional languages such as Java require a lot of ceremony when implementing event sourcing, obscuring the basic simplicity. Using Scala's flexible syntax and support for light-weight classes, immutable data structures and transactional memory only very little support code is needed to build production ready applications using Event Sourcing. We can start simple and scale up to more complexity only when needed. During this talk we'll take a quick tour through thecode you might need to get started.
The goals are to make developers productive while keeping applications understandable and maintainable. This is achieved by:
Putting the developer back into control, instead of a framework
Keeping infrastructure concerns out of your domain code
Manage complexity in a scalable manner. Simple functionality ("CRUD") is easy to implement, while allowing a clear path towards complex behavior and implementation
A simple cost model: the cost of generating, storing, and processing events is clear, as is the cost for querying derived data. With relational databases and ORMs costs are much less clear and often highly dependent on external factors such as configuration, table statistics, etc.
Simple, clearly delineated application components that interact through well-defined interfaces, for both infrastructure and domain code
Mostly immutable data structures with mutation controlled by using Scala's software transactional memory
Some of these concepts were first explored in a series of blog posts and was presentated at ScalaDays in 2011 at Standford University in California.
Friday 14th October 2011
-
Architecture: CQRS in practice – Seven-league boots or just a fairy tale?
by Allard Buijze
With growing communities and on-line activity, applications need to cope with problems related to concurrency and scalability. Two years ago, CQRS –the result of combining several proven best practices- emerged as an architectural pattern to address these problems.
In this talk, Allard will explain how CQRS based architectures address not only concurrency and scalability problems, but also how this pattern supports the developers’ everlasting battle against complexity. The outcome of the session will result in insight in both the opportunities and threats in applying CQRS, based on very practical and down-to-earth scenarios.
Target Audience: Developers, Architects and Technical Managers, or anyone interested in a practical view on CQRS.