TAG | design
In the past I wrote about what CQRS is and now I am adding a list of available CQRS resources known to me. If you come by any other CQRS resources online please post a comment with your link. Thank you.
Video Presentations / Interviews
Greg Young on Unshackle Your Domain
Udi Dahan on CQRS, DDD, NServiceBus
Udi Dahan on CQRS and Domain Models
Greg Young on Architectural Innovation, Eventing and Event Sourcing
Greg Young on CQRS and Event Sourcing: The Business Perspective
Udi Dahan on CQRS
Udi Dahan on CQRS, Race Conditions, Sagas
Udi Dahan on CQRS, Event Sourcing
CQRS/DDD by Greg Young at Professional.NET 2011 in Vienna
Practical CQRS by Rinat Abdullin
Articles / Blogs / Blog Posts
Greg Young’s Blog – a lot of posts on CQRS and related topics.
Think Before Coding – blog posts on CQRS and related topics
CQRS isn’t the answer by Udi Dahan.
Clarified CQRS by Udi Dahan
CQRS a la Greg Young by Mark Nijhof
Brownfield CQRS by Richard Dingwall.
Transitioning from DDD lite by Julien Letrouit
Why I Love CQRS
CQRS on Cloud by Rinat Abdullin
Frameworks, Code Examples
Most of the modern web application frameworks follow the MVC design pattern. It’s probably one of the most misunderstood design patterns in existence. There are a lot of discussions what kind of responsibilities each letter holds. Common misinterpretation in MVC is regarding the letter M.
The Model should be understood as a domain model. Meaning a collection of domain objects. Usually an application has one model that is the domain model. Models are often mistakenly referenced to as singular domain entities. For example an Order, a User or an Account. This leads unwary developers to common application design problems.
It’s common to see a web application to have a directory named “models” with class files inside it. Upon closer inspection one can often find that those classes are the nouns of the application. For example those nouns could be a User, an Order or a Product. In this scenario the MVC Model stands for singular application entities.
Problems start to surface when an application developer has to create reports, do input validation or to implement an ACL. These kind of problems don’t naturally fit into entities. For example getting a report of top 10 products doesn’t naturally fit into any entity. Validating a complex search filter made out of multiple input fields also doesn’t fit into any of the entities.
It’s common to see developers adding logic that doesn’t fit anywhere naturally to controller classes or somewhat close entities. For example adding a top 10 products report to an Order entity class as a static method call. Or validating complicated search filters inside controller actions.
In time this steadily leads to bloated controller and entity classes that later on become fat spaghetti dishes. Controller classes containing thousands of lines of code with more private methods than public ones, entity classes with few state changing methods and hundreds of lines long SQL report queries with joins to 10 tables.
To prevent this from happening it is crucial to understand what controller and model stands for. A controller’s responsibility is only to receive input and initiate a response for the view by making calls on model objects. This means that controllers should be very light and skinny. Usually doing nothing else just instantiating classes, getting data from the domain objects and passing it to the view. Model is not a singular entity and can consist of an entire web of interconnected domain objects. The definition fat model means having as many domain objects as needed. Be it reports, validators, filters, entities, strategies and so on.
Another talk I’ve atended at PHPUK 2010 was AntiPHPatterns by Stefan Priebsch. While design patterns are core implementation independent solutions to problems that occur over and over again which also serve as a great vocabulary, anti patterns are software patterns that are ineffective or counterproductive. In his presentation Stefan describes some of these anti patterns:
1. Constantitis. Excessive use of global constants is considered to be a code smell. Global constants can be defined anywhere in the code base, there is a risk of name clashes if a constant is already defined, global constants make the code more coupled, testing gets more complicated since constants have to be known beforehand and defined explicitly which might be even more troubling if a constant has to change it’s value for another test. Since class constants are not global it’s OK to use them. Cure for constantitis is not to use global constants and instead use dependency injection.
2. Globalomania. Global variables share the same problems as global constants. Because global variables can be changed it makes them more dangerous than global constants since a change in one part of the codebase can affect the other without anyone noticing. Global variables can be cured by using dependency injection.
3. Singletonitis. Singleton is one of the most popular design patterns. It’s wide success is due to the fact that singletons by implementation are available globally in the entire application. The problem that singleton design pattern tries to solve is to prevent having multiple instances of the same class. This is rarely the problem in most applications and most singletons are being used as global variables instead. Singletons share the same problems as global constants and global variables and therefore should be avoided. Singletonitis has the same cure as constantitis and globalomania.
4. God classes. According to object oriented best practices classes should do one thing only and do it well. Classes should be refined and granular. One of the ways to think about this is to ask yourself what are the responsibilities of this class. In an ideal case you will be able to describe it in one sentence without any “and’s”. When classes start having too many responsibilities they become god classes. Usually the whole application relies on one of the god classes which makes the application tight coupled and therefore more difficult to maintain. To cure god classes minimize class responsibilities so that objects know everything about themselves and little about others.
Every web developer probably at some point heard something about MVC unless he or she was living in a cave. I definately have heard and read a lot about it. I won’t probably lie too much to say that most people know that MVC is the nowdays defacto design pattern for web applications. Atleast for PHP it is.
If you have ever had interest in design patterns and did some research on them you may know that design patterns may be interpreted and implemented different every time one tries to. And MVC is no exception to this rule. In my own career path I have seen many projects that claim to implement the MVC design pattern. And if it actually doesn’t – it may be called a hybrid of MVC. As ridiculous as it may be I think because of the MVC hype and everyone trying to be able to claim “yes we use MVC” it is one of the most misunderstood patterns of them all. And because of this … There are a LOT and i mean a LOT of articles and blogs and forums trying to explain MVC the way it should be.
And I myself have read a lot of versions of these blogs and articles. And to be honest I couldn’t answer to you for example what a controller should do and should not do. Well ofcourse I know it shouldn’t contain any business logic. If you would try to research that you would probaly find people saying that the controller should initiate the model, do something with the model and pass the result to the view and render it. You can even find some examples..
But to some extent I find it all synthetic and not very realistic. Most examples are of the level of Hello World program. I think the devil is in the details. If you would try to find any sample php mvc applications you probably wouldn’t find much. There are a few very simplistic sample MVC projects but I don’t find that to be an eye opener that goes deep into details.
I think the PHP community needs such an example. I believe Zend Framework is a great start for MVC. But it isn’t enough. It still doesn’t show you how a real life model or controller would look like. What each part of MVC would do and would not. I believe that one good example is better than a thousand words. I feel trully interested to try and find the “Equilibrium” of the famous MVC design pattern. Don’t you?