Category Archives: CQRS

How we got rid of the database–part 2

A quick introductory sample – continued In part one of this series I started to explain what we do, when e.g. a user (in the particular case a principal investigator) wants to schedule a new task. In this case a … Continue reading 

Also posted in Agile, Community, Kaizen, Lean Systems, Philosophy of Software, Standardized Work | 4 Comments

How we got rid of the database

A quick introductory sample – Part 1 I want to write a series of posts which describe in detail how we do things in my company. What architecture do we use, which patterns do we follow, and more specifically, how … Continue reading 

Also posted in Kanban, Management, Metrics, Tools and Vendors | 11 Comments

Anders Hejlsberg Is Right: You Cannot Maintain Large Programs In JavaScript

There’s a quote over on a Channel 9 video of Anders Hejlsberg: Erik Meijer: Are you saying you cannot write large programs in JavaScript? Anders Hejlsberg: No, you can write large programs in JavaScript. You just can’t maintain them. With … Continue reading 

Also posted in AntiPatterns, Composite Apps, Craftsmanship, Javascript, Philosophy of Software, Pragmatism, Principles and Patterns, Risk Management | 29 Comments

Adding Request / Reply To The Application Controller

Back in December of 2009 I had a post on using various messaging patterns within an application controller as part of an application’s architecture. One of the patterns that I distinctly left out was request/reply. At the time I had … Continue reading 

Also posted in .NET, Analysis and Design, AppController, C#, Compact Framework, Design Patterns, Messaging, Pragmatism, Principles and Patterns | 4 Comments

CQRS Performance Engineering: Read vs Read/Write Models

I’ve used a lot of different architectures, patterns and implementations that revolve around the core concept of command-query separation (CQS) and the more recent label of command-query responsibility separation (CQRS). The ideas behind these principles help us create code that … Continue reading 

Also posted in Analysis and Design, Pragmatism, Principles and Patterns | 6 Comments