CQRS the simple way.

CQRS stands for Command Query Responsibility Segregation and is a pattern that splits an application into two parts: Commands and Queries.
Queries are used to get data from a datasource (like a database) and commands are used to do something with the data.
The simplest form of CQRS is the following:

public interface BlogQueryService
{
    IEnumerable<Blog> GetAllBlogPosts();
    Blog GetBlogPost(int blogid);
    IEnumerable<Comment> GetAllCommentsForPost(int blogid);
}

public interface BlogCommandService
{
    void NewBlogPost(string title, string text);
    void EditBlogPost(Blog editedBlog);
    void AddComment(int blogid, string comment);
}

The BlogCommandService just updates the datasource with the given data (and does validation if needed) the query service just return simple data.
Of course this is not scalable and a lot of advantages that Udi Dahan and Greg Young describe are not here, but it is a first step to decouple a lot of applications.

Make development easier and faster with unit testing

As software developers we always come across bugs, some bugs are not very difficult to fix and other bugs are more difficult. Sometimes it is even hard to find the place in code where the bug is coming from and sometimes when we fix a bug we introduce several other without knowing it.
The solution for this problem are unit tests.

Another problem we have is that the user wants to know that the software (s)he is using is reliable. We as software developers should be able to tell the user that the software we are writing is reliable. And we should be able to tell that we have implemented features the way the user wants it and not the way we think they want it or should use it. Basically the user is king.
The way to get some reliability is unit testing.

So what are unit tests?
A unit test is code that is testing the software we have been writing or are going to write. You can test software on multiple levels.
First we can test functions/methods directly like this:

public int Add(int x, int y)
{
    return x + y;
}

[Test]
public void TestAdd()
{
   int result = Add(2, 3);
   Assert.AreEqual(5, result);
}

Second you can test bigger parts of the system:

   1:  [Test]

   2:  public void When_playing_files_that_donot_exist_give_error()

   3:  {

   4:      ProgramPlayer player = new ProgramPlayer();

   5:      try

   6:      {

   7:         player.Play("filethatdoesnotexist.mp3");

   8:         Assert.Fail("Exception was not thrown");

   9:      }

  10:      catch(FileNotFoundException ex)

  11:      {

  12:          Assert.IsNotNull(ex);

  13:      }    

  14:  }

And you can test complete usecases and programs.

For most people it seems like wast of time to write unit tests. When I first started with unit tests it was like I wasted time (although at that time I was at university), but after some time and a lot of improvements I realized that unit testing does help. Last year I had to write code for some really difficult calculation. A colleague made the calculations on paper so that I could validate it.
So I wrote some tests for all those calculations and I started to work out a solution.
I soon found out that is was easy to split up the solution in multiple parts, so I wrote unit tests for each part of the solution as well and soon I had a working implementation.
At that moment I didn't even have a user interface to test it in. I found out that working with unit testing is much faster than without. You can test specific parts of the program very fast without the need of starting the application and navigate to the place where you are using the feature you are testing.