Ehsan Ghanbari

Experience, DotNet, Solutions

Simple command handler in .net

 

I want to introduce a simple command handler pattern in order to separate commands and queries of your applications if it’s needed. Sometimes especially in large-scale applications, you need to have two layers for reading and write separated and assign two teams to work on them.

You can use the pattern in this post based on the complexity and needs of your application. I recommend that don’t call this CQRS pattern as it’s something completely different and more complex.

 

Get started and Create an interface with no any member:

public interface ICommand

    {

    }

You will see later in this blog post that ICommand is just a flag to determine the commands for the handler. Every command which is trying to make a change in application’s state should return a result. so create another interface named ICommandResult

public interface ICommandResult

    {

        string Message { get; }

        bool Success { get; }

    }

implement the above interface as CommandResult and derive the FailureResult and SuccessResult classes from:

internal abstract class CommandResult : ICommandResult

    {

        public string Message { get; protected set; }

        public bool Success { get; protected set; }

    }



internal class FailureResult : CommandResult

    {

        public FailureResult(string message)

        {

            Success = false;

            Message = message;

        }

    }



    internal class SuccessResult : CommandResult

    {

        public SuccessResult(string message)

        {

            Success = true;

            Message = message;

        }

    }

Now create an interface for handling the validations in CommandBus class:

internal interface IValidationHandler<in TCommand> where TCommand : ICommand

    {

        IEnumerable<ValidationResult> Validate(TCommand command);

    }

 And create a class for validations:

public class ValidationResult

    {

        /// <summary>

        /// Initializes a new instance of the <see cref="ValidationResult"/> class.

        /// </summary>

        public ValidationResult()

        {

        }



        /// <summary>

        /// Initializes a new instance of the <see cref="ValidationResult"/> class.

        /// </summary>

        /// <param name="memeberName">Name of the memeber.</param>

        /// <param name="message">The message.</param>

        public ValidationResult(string memeberName, string message)

        {

            MemberName = memeberName;

            Message = message;

        }



        /// <summary>

        /// Initializes a new instance of the <see cref="ValidationResult"/> class.

        /// </summary>

        /// <param name="message">The message.</param>

        public ValidationResult(string message)

        {

            Message = message;

        }



        /// <summary>

        /// Gets or sets the name of the member.

        /// </summary>

        /// <value>

        /// The name of the member.  May be null for general validation issues.

        /// </value>

        public string MemberName { get; set; }



        /// <summary>

        /// Gets or sets the message.

        /// </summary>

        /// <value>

        /// The message.

        /// </value>

        public string Message { get; set; }

    }

And now create the most used interface in this pattern. ICommandBus will be called as bus handler in every command:

public interface ICommandBus

    {

        ICommandResult Send<TCommand>(TCommand command) where TCommand : ICommand;

        IEnumerable<ValidationResult> Validate<TCommand>(TCommand command) where TCommand : ICommand;

    }

To implementing this interface, create a class again with the following definition:

  internal class CommandBus : ICommandBus

    {

        public ICommandResult Send<TCommand>(TCommand command) where TCommand : ICommand

        {

            var handler = DependencyResolver.Current.GetService<ICommandHandler<TCommand>>();



            if (!((handler != null) && handler != null))

            {

                throw new CommandHandlerNotFoundException(typeof(TCommand));

            }

            return handler.Execute(command);

        }



        public IEnumerable<ValidationResult> Validate<TCommand>(TCommand command) where TCommand : ICommand

        {

            var handler = DependencyResolver.Current.GetService<IValidationHandler<TCommand>>();

         

            if (!((handler != null) && handler != null))

            {

                throw new ValidationHandlerNotFoundException(typeof(TCommand));

            }

            return handler.Validate(command);

        }

    }

The above class will handle every command received from the bus. And now for executing the handler or so-called for implementing the business, you need an interface:

internal interface ICommandHandler<in TCommand> where TCommand : ICommand

    {

        ICommandResult Execute(TCommand command);

    }

And finally as I’m personally interested in to have my own exception handler, so I create a customized handler:

public class CommandHandlerNotFoundException : Exception

    {

        public CommandHandlerNotFoundException(Type type)

            : base(string.Format("Command handler not found for command type: {0}", type))

        {

        }

    }



    internal class ValidationHandlerNotFoundException : Exception

    {

        public ValidationHandlerNotFoundException(Type type)

            : base(string.Format("Validation handler not found for command type: {0}", type))

        {

        }

    }

Finished! Now let’s use the above codes in a real work application. We are going to handle the products of an e-commerce application as its business is easier to comprehend for everybody:

    public interface IProductCommand : ICommand

    {

        string Name { get; set; }



        string OriginalName { get; set; }



        string Description { get; set; }



        decimal Price { get; set; }

     

    }

  

    public class ProductCommand : IProductCommand

    {

        public string Name { get; set; }



        public string OriginalName { get; set; }



        public string Description { get; set; }



        public decimal Price { get; set; }     

    }



    public class CreateProductCommand : ProductCommand

    {

    }



    public class EditProductCommand : ProductCommand

    {

        public Guid ProductId { get; set; }



        public DateTime CreationDate { get; set; }



        public DateTime LastUpdateDate { get; set; }

    }



public class DeleteProductCommand : ICommand

    {

        public Guid[] ProductIds { get; set; }

    }

You can see that I created an interface derived from ICommand named IProductCommand and finally created the target classes. And at the end we should create the Product handler class:

internal partial class ProductCommandHandler :

        ICommandHandler<CreateProductCommand>,

        ICommandHandler<EditProductCommand>,   

        ICommandHandler<DeleteProductCommand>       

    {

        private readonly IProductRepository _productRepository;

        private readonly IMembershipRepository _membershipRepository;     

        private readonly IUnitOfWork _unitOfWork;

        private readonly ICacheManager _cacheManager;

        private readonly ILogger _logger;



        public ProductCommandHandler(

            IProductRepository productRepository,        

            IUnitOfWork unitOfWork,

            ILogger logger,

            ICacheManager cacheManager)

        {

            _productRepository = productRepository;          

            _unitOfWork = unitOfWork;

            _logger = logger;

            _cacheManager = cacheManager;        

        }

       

        public ICommandResult Execute(CreateProductCommand command)

        {

            try

            {

                if (command == null)

                {

                    throw new ArgumentNullException();

                }



                var product = new Product();

                AddProductAppurtenance(command, product);

                _productRepository.Add(product);

                _unitOfWork.Commit();

                return new SuccessResult(ProductCommandMessage.ProductCreatedSuccessfully);

            }

            catch (Exception exception)

            {

                _logger.Error(exception.Message);

                return new FailureResult(ProductCommandMessage.ProductCreationFailed);

            }

        }



        public ICommandResult Execute(EditProductCommand command)

        {

            try

            {

                if (command == null)

                {

                    throw new ArgumentNullException();

                }



                var product = _productRepository.GetProductDetailById(command.ProductId);

                ClearProductAppurtenance(product);

                AddProductAppurtenance(command, product);

                _productRepository.Edit(product);

                _unitOfWork.Commit();



                return new SuccessResult(ProductCommandMessage.ProductEditedSuccessfully);

            }

            catch (Exception exception)

            {

                _logger.Error(exception.Message);

                return new FailureResult(ProductCommandMessage.ProductEditionFailed);

            }

        }



        public ICommandResult Execute(DeleteProductCommand command)

        {

            if (command.ProductIds == null)

            {

                throw new ArgumentNullException();

            }



            var exceptions = new List<Exception>();

            foreach (var productId in command.ProductIds)

            {

                try

                {

                    var product = DeleteProduct(productId);

                    _productRepository.Edit(product);

                }

                catch (Exception exception)

                {

                    exceptions.Add(exception);

                    return new FailureResult(ProductCommandMessage.ProductDeletionFailed);

                }

            }



            if (exceptions.Any())

            {

                throw new AggregateException(exceptions);

            }



            _unitOfWork.Commit();

            return new SuccessResult(ProductCommandMessage.ProductsDeletedSuccessufully);

        }  

 

We used all of the classes introduced in infrastructure.

Note 1: so you need to have an IOC container tool, to the best of my Knowledge, AsClosedTypesOf in Autofac resolves the ICommandHandler. This a piece of code I wrote for IOC handler:

  public class CommandModule : Module

    {

        protected override void Load(ContainerBuilder builder)

        {

            builder.RegisterModule<RepositoryModule>();

            builder.RegisterType<CommandBus>().As<ICommandBus>().InstancePerRequest();

            builder.RegisterAssemblyTypes(ThisAssembly).AsClosedTypesOf(typeof(ICommandHandler<>)).InstancePerRequest();

        }

    }

Note 2: a penny for your thoughts! how to use ICommandBus!? See the below piece of code as an example:

[HttpPost]

        public JsonResult DeleteProduct(DeleteProductCommand command)

        {

            var result = _commandBus.Send(command);

            return JsonMessage(result);

        }

have fun.



Disadvantages of n-layered architectures

Most of the people use n-layered architectures in their application development. There are lots of advantage for n-layered architecture but I want to talk about the disadvantages. actually, it's not a good idea to design a complex architecture for every problem, you don't need to apply n-layered architecture in every case because it's mostly about making complex things simple whilst a complex architecture can make a system more and more hard to understand rather than making performance problems. Based on this presentation, making software via n-layered application could be cost-effective and dangerous for performance. Suppose an architecture like the picture below:

n-layered

 

When you make a request from your browser your request goes throw several layers and assemblies to persist your request in database and then comes back the same way to make a change (you can simply assume the scenario like the picture!). Let's take an example about that, imagine that I'm gonna to persist the sent message(Contact) by the user in "ContactUs" of the n-layered architecture website (the same example I showed in StackOverflow).

This is my action to create the Contact:

 

[HttpPost]
public ActionResult Create(ContactViewModel contactViewModel)
{
    var request = new CreateContactRequest(contactViewModel);
    _contactService.CreateContact(request);
    return View();
}

 

and about the service implementation, I've done like this:

 

public CreateContactResponse CreateContact(CreateContactRequest request)
{
    var response = new CreateContactResponse();
    var contact = request.ContactViewModel.ConvertToContactModel();
    try
    {
        _contactRepository.Add(contact);
        _unitOfWork.Commit();
        response.Success = true;
        response.MessageType = MessageType.Success;
        response.Message = ServiceMessages.GeneralServiceSuccessMessageOnCreation;
        _logger.Log(response.Message);
    }
    catch (Exception exception)
    {
        response.Success = false;
        response.MessageType = MessageType.UnSuccess;
        response.Message = ServiceMessages.GeneralServiceErrorMessageOnCreation;
        _logger.Error(exception.Message);
    }
    return response;
}

  

And  finally in the repository layer, I have this generic Add method:

 

public void Add(T entity)
{
    SessionFactory.GetCurrentSession().Save(entity);
}

 

As you can see there are lots scenario in this example such as converting ViewModel to Model, using request and response pattern in Service, injecting the interfaces,  adding to the repository, committing by UnitOfWork and blah blah. But you I can also do all of above with just a simple action method:

 

[HttpPost]
public ActionResult Create(Contact contact)
{
    SessionFactory.GetCurrentSession().Save(contact);
    return View();
}

 

You know the above implementation on an action is not the best solution when your application is complex and large scale, but if it is not trying to use something like that as it's easy to develop and defiantly high performance.

Optimizing n-layered architectures is not an easy task, But it is easy to change the content of any layer without making corresponding changes in other layers. It is more readable, maintainable, extensible, flexible, testable and is suitable for parallel development especially in team working but you know it has its own disadvantages.

If you have enough factors to break your application into layers, for example, if you want to let other applications to access to your application via a service, separate your concerns; so apply to layered architecture but keep in mind that:

 

  1. This architecture leads to the reduction of network traffic, faster network communications, greater reliability, and greater overall performance.
  2. As layers usually live in separate assemblies so This results in high communications overhead.
  3. More layer cause more network and network bandwidth, the process involved. 



Domain driven design VS model driven architecture

Domain Driven design(DDDesign) is not the same Model Driven Architecture(MDA). Although The root of both DDDesign and MDA is the same and it is Model Driven Engineering and also both of them aim to solve the problem of converting a 'pure' problem domain model into a full software system. But there are some differences.

Domain Driven Design concentrates on Modeling and solving the Domain problem by Capturing the model from the Ubiquitous language. it is about modeling a domain of knowledge with a high level of abstraction and its focuses are on domain logic and tries to keep the design as much close to the real world. In DDDesign you create the model with the Ubiquitous language so you should understand the business without any technical issues. In another side, model forms the ubiquitous language of DDDesign which explains the domain in a simple form and it's kinda a backbone of DDDesign.

But Model-driven architecture is an approach to building the model of the system. As I mentioned MDA is a kind of domain engineering too. A model is just some taken classes, methods and ... from the problem domain. MDA provides you to use multiple standards such as UML. 

 

but you know it doesn't stop there, I don't know more than these two paragraphs about differences of DDD and MDA! please let me know more about these two architectures and differences by comments, thanks...



Most common architectures of enterprise applications

"An effective enterprise application should be divided into layers", An Enterprise application should have the flexibility, maintainability, scalability, testability, and extensibility. And to achieve this there are some techniques and principles like Separation of concern in layers and components and loose coupling. And if you are developing a web application, in order to make it secure and accessible, you need to distribute the application over multiple physical tiers. To ensure high performance and reliability, the application must be testable. Now I'm going to describe some architectural contexts just notice that I'm just talking about different kinds of layers and tiers and based on your solution and business you can apply each of them and you don’t need to have all of them in every enterprise application.

 

 

What is the layered architecture? 

Layering is mostly about allocating specific responsibilities for the software. Maybe you have heard about "tier" instead of layer, it's OK! But tire mostly used for representing physical layout it's a project in the solution (in .NET), but the layer is not just a project in the solution although it could be. A layer is a conceptual element which could be consist of several tiers. So a tier could be a layer and vice versa but not in all the cases, in the real world several tiers could represent a layer. A Layer is completely separated from other layers and boundaries are supported by interface contracts. There are some Common layers that you can find in most of the enterprise application:  infrastructure layer, Domain Layer, Application layer, Service layer, Presentation layer

 

 

Infrastructure and crosscutting Layer

"The Infrastructure Layer contains the standards and best practice designs for the underlying platform components", which enable the adequate functioning of all other layers. Infrastructure contains some basic and common configuration for all of the layers in the project such as Domain Events, Validations, basic Helpers, Unit Of work and etc.  Maybe you have heard about the crosscutting layer, you can merge it with infrastructure layer. You can put authentication, authorization, Email, Logging, and service in crosscutting(if you have separated it from infrastructure).

 

 

Domain Layer

A domain is the heart and hardest part of the software. Designing the correct Domain model could guarantee software success. A domain is not just about some properties (domain objects) which represent fields of tables in the database. Complex business rules, behaviors should be solved in the domain layer. If you would like to know more about Domain Layer, you should go to the world of Domain Driven Design!

 

 

Data Access Layer and Repository

As I mentioned here before, Data access layer is something different from the repository, if you have a business object in your domain then you can have data access layer but if you have Aggregate(DDDesign) you can have Repository layer. The data layer provides access to external systems such as databases. You can use Microsoft Entity framework or Non-Microsoft open source ORM like NHibernate in your DAL or Repository layer.

 

 

Services Layer

"The services layer defines the composite set of functions that are required to create a reliable, secure, and transacted service." A set of specifications define the standard operating behavior for the services and enables them to be aggregated or composed into other applications. An application exposes some of its functionality for using other services or frameworks by service interface. By dependency injection tools you can make it lose coupled. It's so common to separate service interfaces from service implementation in other layers.

 

 

Business Layer

"Large enterprise applications are often structured around the concepts of business processes and business components." The business layer implements the business functionality of the application. Business logic should be separate from the presentation.

 

 

Presentation Layer

The presentation layer provides the application's user interface. It could be any framework, for example in .NET it could be Asp.net MVC, Asp.net WebForm, Silverlight, WPF and so on. Presentation layer talks to service layer interfaces.

 

 

 

Related posts

  1. http://msdn.microsoft.com/en-us/library/ff650258.aspx
  2. http://www.cs.bgu.ac.il/~oosd051/uploads/classes/4-Layered-architectures.pdf
  3. http://msdn.microsoft.com/en-us/library/ee658109.aspx
  4. http://codeidol.com/community/java/what-is-a-layered-architecture/10833/
  5. http://msdn.microsoft.com/en-us/library/ff648105.aspx



Definition of Command Query Responsibility Segregation

 

What is CQRS?

CQRS Is an alternative architecture and pattern for Domain Driven Design (But you don’t basically need DDD to apply CQRS). A method should either change the state of an object, or return a result, but not both. In other words, asking the question should not change the answer. CQRS is a pattern that strictly segregates the responsibility of handling command input into an autonomous system from the responsibility of handling side-effect-free query (read) access on the same system.  In simple terms, your service implementation for the query should be separated from command. Just like REST terminology, get and query requests is something different from the push, delete and update. So you can optimize the read side of the system separately from the write side. The write side is known as the domain and The domain contains all the behavior.  You can bypass the domain model and get DTOs directly from the data storage using a read layer. When an application is requesting data, this could be done by a single call to the read layer which returns a single DTO containing all the needed data.

 

CQRS and DDD

Domain-Driven Design is extremely important for successfully delivering and maintaining CQRS-based systems. DDD works as a strategic approach that allows breaking complex problem domains into separate blocks (called bounded contexts) while accounting for things like different mental models, organizational politics, domain linguistics etc. While doing that, DDD establishes a mental model of bounded context, that is both understandable by business people and can easily be implemented in the code. The reasons for identifying context boundaries for your domain models are not necessarily the same reasons for choosing the portions of the system that should use the CQRS pattern. In DDD, a bounded context defines the context for a model and the scope of a ubiquitous language. You should implement the CQRS pattern to gain certain benefits for your application such as scalability, simplicity, and maintainability. Because of these differences, it may make sense to think about applying the CQRS pattern to business components rather than bounded contexts.

 

Read and write sides

Objects or the read side contain only query methods, and the objects on the "write" side contain only command methods. you can scale out the read side to support the larger number of reading operations independently of the write side. Typically, commands involve complex business logic to ensure that the system writes correct and consistent data to the data store.  A single conceptual model that tries to encapsulate both read and write operations may do neither well. Segregating the two sides ultimately results in simpler, more maintainable, and more flexible models. With CQRS you can achieve great read and write performance. By separating read and write operations, each can be optimized. With CQRS you can split development tasks between different teams with defined interfaces (read and write).  A direct connection to the data source makes queries very easy to buy maintained and optimized. So It makes sense to denormalize data. The reason for this is that data is normally queried many times more than the domain behavior is executed. This denormalization could increase the performance of the application.

Command: change the state of an object or entire system. A command changes the state of an object but does not return any data.

Query: return results and do not change the state of an object. queries will declare the return type. The reading layer can be directly connected to the database and query via a stored procedure or an ORM. A query returns data and does not alter the state of the object. In the picture below (described in Microsoft articles which I've referenced at the end), a user requests and make the change in the state of the system and receives via query side.

                                  Command/Query

 

Events in CQRS

   1-Internal Event:  The domain event is something that has happened in the system in the past. The event which is handled inside the aggregate root of DDD is called an internal event. The event handler should not be doing any logic instead of setting the state. every state change of an Aggregate Root is triggered by an event and the internal event handler of the Aggregate Root has no other role than setting the correct state.  If you find that some logic in your system is generating the wrong events, you must generate a new compensating event correcting the results of the previous bug events.

 

   2-External event: External events are usually used for bringing the reporting database in sync with the current state of the domain. This is done by publishing the internal event outside the domain. When an event is published then the appropriate Event Handler handles the event. External events can be published to multiple event handlers.

 

The Event handlers perform the following tasks:

  1. It receives an Event instance from the messaging infrastructure (Event Bus).
  2. It locates the process manager instance that is the target of the Event.
  3. It invokes the appropriate method of the process manager instance passing in any parameters from the event.
  4. It persists the new state of the process manager to storage.
  5. But who can publish the events? Usually, the domain repository is responsible for publishing external events.
  6. The only entry point for the CQRS example is the Command Bus into which commands are sent. 

 

 

What kinds of problems does CQRS solve?

Scalability: In many enterprise systems, the number of reads vastly exceeds the number of writes, so your scalability requirements will be different for each side. By separating the read side and the write side into separate models within the bounded context, you now have the ability to scale each one of them independently. Scalability should not be the only reason why you choose to implement the CQRS pattern in a specific bounded context.

 

Reduced complexity: In complex areas of your domain, designing and implementing objects that are responsible for both reading and writing data can exacerbate the complexity. In many cases, the complex business logic is only applied when the system is handling updates and transactional operations; in comparison, read logic is often much simpler. When the business logic and read logic are mixed together in the same model, it becomes much harder to deal with difficult issues such as multiple users, shared data, performance, transactions, consistency, and stale data. Separating the read logic and business logic into separate models makes it easier to separate out and address these complex issues. However, in many cases, it may require some effort to disentangle and understand the existing model in the domain. Separation of concerns is the key motivation about Command Query Separation Principle. Like many patterns, you can view the CQRS pattern as a mechanism for shifting some of the complexity inherent in your domain into something that is well known, well understood, and that offers a standard approach to solving certain categories of problems. Another potential benefit of simplifying the bounded context by separating out the read logic and the business logic is that it can make testing easier.

 

"The really valuable idea in this principle is that it's extremely handy if you can clearly separate methods that change state from those that don't. This is because you can use queries in many situations with much more confidence, introducing them anywhere, changing their order. You have to be more careful with modifiers."

                                                                       —Martin Fowler, CommandQuerySeparation

 

 

When Should I choose CQRS?

Because of separating the read and write side, it is useful for Task-based and inductive User interfaces applications. Using the CQRS  pattern could be valuable when your system has a collaborative and large amount of data, complex and ever changing business rules. CQRS forces you to not mix domain logic and infrastructural operations. CQRS is not useful in any case, like other patterns. CQRS could be implemented on a bounded context and also could be used in the whole of the system. A complex domain may be easier to tackle by using CQRS.  Each domain has different characteristics, usually, there's enough overlap between the command and query sides that sharing a model is easier. CQRS allows you to separate the load from reads and writes allowing you to scale each independently. The other main benefit is in handling high-performance applications. If your application sees a big disparity between reads and writes this is very handy. Even without that, you can apply different optimization strategies to the two sides. An example of this is using different database access techniques for reading and update. In general, applying the CQRS pattern may provide the most value in those bounded contexts that are collaborative, complex, include ever-changing business rules, and deliver a significant competitive advantage to the business. Analyzing the business requirements, building a useful model, expressing it in code, and implementing it using the CQRS pattern for such a bounded context all take time and cost money. You should expect this investment to pay dividends in the medium to long-term. It is probably not worth making this investment if you don't expect to see returns such as increased adaptability and flexibility in the system, or reduced maintenance costs.  You can apply CQRS when you need to migrate your architecture towards an event-driven architecture - CQRS as a pattern is a good stepping stone. it's hard to get face-to-face communication, so you want to decouple the read models from the write-side of things (sagas, domain, CRUD) and you want to formalize the data merge concepts of your domain you want to scale horizontally and not vertically.

 

 

When not to  Use CQRS?

You should not apply the CQRS pattern to the top level of your system. You should clearly identify the different portions of your system that you can design and implement largely independently of each other, and then only apply the CQRS pattern to those portions where there are clear business benefits in doing so. If you are not developing a highly collaborative system where you don't have multiple writers to the same logical set of data you shouldn't use CQRS. Simple, static, non-core bounded contexts are less likely to warrant the up-front investment in detailed analysis, modeling, and complex implementation. Again, non-collaborative bounded contexts are less likely to see benefits from applying the CQRS pattern. In most systems, the majority of bounded contexts will probably not benefit from using the CQRS pattern. You should only use the pattern when you can identify clear business benefits from doing so. CQRS naturally fits with some other architectural patterns. As we move away from a single representation that we interact with via CRUD, we can easily move to a task-based UI. Having separate models raises questions about how hard to keep those models consistent, which raises the likelihood of using eventual consistency. CQRS is suited to complex domains, the kind that also benefits from Domain-Driven Design.

 

"It's important to note though, that these are things you can do, not necessarily things you should do. Separating the read and write models can be quite costly."

                                                                      —Greg Young, CQRS and CAP Theorem.

 

 

I covered some basic concepts about CQRS pattern if you take a look at these pictures you can find out how it works and what's CQRS for.

 

            CQRS

 

 

             CQRS

 

 

               CQRS

 

 

Summary

The CQRS pattern is an enabler for building individual portions (bounded contexts) in your system. Identifying where to use the CQRS pattern requires you to analyze the trade-offs between the initial cost and overhead of implementing the pattern and the future business benefits. Useful heuristics for identifying where you might apply the CQRS pattern are to look for components that are complex, involve fluid business rules, deliver competitive advantage to the business, and are collaborative. I collected some information about CQRS pattern in this article, as I'm learning this pattern I'm sure that it might be some kinds of technical mistakes in it, so I would be thankful if you tell me about that.

 

References

  1. http://msdn.microsoft.com/en-us/library/jj554200.aspx
  2. http://msdn.microsoft.com/en-us/library/jj591560.aspx
  3. http://msdn.microsoft.com/en-us/library/jj591573.aspx
  4. http://www.codeproject.com/Articles/555855/Introduction-to-CQRS
  5. http://martinfowler.com/bliki/CQRS.html
  6. http://blog.fossmo.net/post/Command-and-Query-Responsibility-Segregation-(CQRS).aspx
  7. http://codeofrob.com/entries/cqrs-is-too-complicated.html
  8. http://cqrs.wordpress.com/
  9. http://codebetter.com/gregyoung/2010/02/16/cqrs-task-based-uis-event-sourcing-agh/
  10. http://www.codeproject.com/Articles/342939/Lessons-learned-when-applying-DDD-CQRS
  11. http://cqrs.wordpress.com/documents/cqrs-and-event-sourcing-synergy/



About Me

Ehsan Ghanbari

Hi! my name is Ehsan. I'm a developer, passionate technologist, and fan of clean code. I'm interested in enterprise and large-scale applications architecture and design patterns and I'm spending a lot of my time on architecture subject. Since 2008, I've been as a developer for companies and organizations and I've been focusing on Microsoft ecosystem all the time. During the&nb Read More

Post Tags
Pending Blog Posts
Strategic design
Factory Pattern
time out pattern in ajax
Selectors in Jquery
using Log4net in asp.net MVC4
How to use PagedList In asp.net MVC
Redis as a cache server
Domain driven design VS model driven architecture
What's the DDD-lite?
Multiple submit buttons in asp.net MVC