Sep 24 2011

Talking at Norwegian .NET User Group next thursday

Category: CQRS | Database | DDD | WPFfossmo @ 09:49

The last three years I have been working for a customer in Trondheim, Norway, building a application based on Windows Presentation Foundation (yeah, I know it's not the hottest stuff), SQL Server, Entity Framework 4.1 (Code first) and a cool scalable architecture. At the user group meeting I will present how we buildt the architecture and how we solved the problems around scalability. I'm looking forward to presenting this stuff for the user group and hope to see you there!!

Sign up for the meeting at http://www.nnug.no/Avdelinger/Trondheim/Moter/NNUG-Trondheim---29-september-2011/ 

Tags: ,

Currently rated 1.5 by 248 people

  • Currently 1.504034/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Feb 23 2010

I’m doing a presentation about CQRS

Category: CQRS | DDDfossmo @ 16:53

On Thursday, 4. march I will be holding a presentation about my experience using CQRS in a project for a customer. The meeting is held in Trondheim at the Vital building. During the meeting I will be giving away 2 licenses for CodeRush™ with Refactor!™ Pro. To participate in this event, go to www.nnug.no and register there.
Hope I will see you there

1266961907_1

Tags:

Currently rated 3.0 by 10 people

  • Currently 3/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Jan 7 2010

Five things to think about when working with messaging solutions

Category: DDD | Patterns | Messagesfossmo @ 16:21

I’m trying to gather some of my thoughts around messages and that resulted in these 5 points:

1) A message can be created with any technology. It can be JSON, XML, Binary or a custom format. If you want to use the message in different technologies (like Java and .NET), it might be smart to go for a format supported by both technologies. Well, if you choose a technology like XML, it’s not given that you can exchange messages. XML is just a way to format your message, it doesn’t say anything about the content.

2) A message consists of two basic parts; a header and a body.
The header describes the data being transmitted and the body holds the data being transmitted.

3) The tree most important message types are (as I see it); document messages, command messages, event messages. You can read more about this messages in the book Enterprise Integration Patterns: Designing, Building, and Deploring Messaging Solutions (I’m linking to the kindle edition. I love my Kindle :-) ).

A bit more about this message types: A command message is a regular message that contains a command. It uses the command pattern to, for example, encapsulate the request and send it to another system. A document message is used to transferee a data structure between applications and a event message is used to notify another system about a change; for example a price change.

4) When working with messages, you need a way to handle them. On the .NET platform there are several open source choices; NServicebus, Rhino Servicebus, Simple Servicebus and MassTransitt (it’s probably more solutions out there). I think all of them uses MSMQ when communicating the messages, but there are other ways too. There are probably some commercial products out there too, but I haven’t tried to look them up at the moment. For the record; you don’t need a enterprise service bus handle messages. A message can be used to communicate internal in an application, for example between bounded contexts.

5) Messages are immutable. You can look at them as value objects. Greg Young puts it like this; Mutable messages are an anti-pattern. You can read more about his at Greg Youngs blog.

Tags: , ,

Currently rated 3.0 by 5 people

  • Currently 3/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Dec 8 2009

Update to the CQRS figure

Category: DDD | CQRSfossmo @ 16:33

I did an update to the figure showing how I have implement the CQRS architecture.  As you can see from the figure, I have added a “message-pipeline” from the application service to the denormalizer. The reason is to show that all the updates to the read databases goes through this “pipeline”. The messages will for example be added to a queue or bus. The read databases then will pick up the new messages from the queue or bus, and update itself. I have left the synchronization arrow in the figure because it is used to initialize the read databases based on the write database. I have also done a update on how I have named the different layers and tires in the figure.

image

Tags: ,

Currently rated 3.6 by 8 people

  • Currently 3.625/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Nov 23 2009

Command and Query Responsibility Segregation (CQRS)

Category: DDD | DND | CQRSfossmo @ 16:29

It’s almost one year since I read the “blue book”. It changed my view on how I write software and how I build software architecture. During my time as a software developer, I have tried many different approaches on building software. A lot of the approaches includes an anemic domain model. It’s nothing wrong with building an anemic domain model, but for applications with a bit more complex business logic, it might not be the best choice. You can end up with a lot of “spaghetti code” with high coupling between the different parts of the code. Anemic domain models have their business logic spread “all over” the code and you often have to do updates multiple places in your code if a business rule is changed. And you want to avoid that. Keep this in mind when you code:

“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live” – M. Golding

A classis rich domain model holds all the business logic inside the model and most of the objects are connected to eachother. It strives to be a model that solves the domain logic for the business in one perfect model. And this is often where this way of writing software fails. You get a big model that finally gets very unwieldy. You should rather think bounded context, but that’s not the topic for this post.

Split the model

pie Instead of trying to solve everything in one model; split it into smaller parts and work with each part on its own. Create aggregates that naturally fits together. An example can be a car and a customer. In this example, both are aggregate roots. You should consider to not model both objects and their aggregates into one model. Think of them as small separated models inside the model. This will make the model much easier to handle when persisting and loading into memory.

Greg Young had a great example when he was explaining aggregate roots and how they should work. If a teacher is asked by the headmaster for a overview of his students, he will not bring all the students to the the headmasters office, but he will bring a list with the student information the headmaster wants. For the most part, there are no good arguments for putting everything in one big connected model.

The problem with relational databases

Nowadays many use ORM frameworks to persist data from the domain model to the database, and they use a relational database as the database (are there others? ;-)). A problem with the relation databases is that you have to do a compromise on speed regarding reading and writing data. If you normalize the database, it will be better at inserting, updating and deleting data, but not reading data. The problem are indexes. These buggers will in most cases slow down your select operations but help insert, delete and update operations.

 Update: I have received some comments on this statement. What I was trying to say is: If you add indexes to improve update/delete operations, it might affect the selects you do against the database. You have to do a compromise; either you read faster or write faster.

If you decide to make the database better at reading data (selecting), one option is to de-normalize the database. A de-normalized database means tables with repetitive data and possibly tables with a number of columns from hell.

As developers we often don’t give much thought to this question; how to scale the solution? I think we should keep this thought in the front of your head when you create a solution that may have to serve a lot of users. I’m not saying you should try to predict the future, but with some simple measures from the start, you do not have to think much of it later.

Command and Query Responsibility Segregation

Most applications reads data more frequently than they write data. Based on that statement, it would be a good idea to make a solution where easily you can add more databases to read from, right? So what if we set up a database dedicated just for reading? Even better; what if we design the database in a way so it’s faster to read from it? If you design your applications based on the patterns described in CQRS architecture, you will have a solution that is scalable and fast at reading data. Command Query Separation (CQS) is a pattern that was first thought of by Bertrand Meyer. He described it on the object level. Later this pattern has been lifted from the lower levels and has been used in the higher architectural level. I think it was Udi Dahan who first started talking about this architectural principle.

In this post I describe an architecture that is quite close to the one Udi is talking about. There are several implementations of this pattern, and one of them is described by Greg Young. Greg Young's flavor of the pattern describes CQRS and Event Sourcing. I won’t go into this flavor in this post. If you want to learn more about this flavor, Google for it.

A quick walkthrough of the CQRS architecture

A graphical overview of the architecture is shown in the figure below. Lets do a quick walkthrough of the figure. A user opens an application and the first screen is loaded. The data is fetched from the Query side. In this example it goes through a WCF service and uses, lets say NHibernate, to read data from the database and into a DTO that returns the data to the GUI. The DTO is tailored to fit the screen the user is viewing. The query database is often de-normalized to improve reading. The user may brows through different screens, and the process is the same. A DTO tailored for the users screen is returned from the database. Eventually, the user wants to change the data in one of the screens. What then happens is that a command message is created based on the data that have changed in the view and sent down the left side of the figure; the command side. The command message is sent into the domain model to get validated against the business rules. A error message is sent back to the client if some of the business rules fails (how this is done can differ). If the message goes through the domain model without errors, it’s persisted to the write database and synchronized with the read database(s). The command side should never return other data than the error message. If you follow this rule, the command side will only be behavioral. This makes logging of what happens in the domain model very easy, and it’s quite easy to track what the user wanted to do, not only what the result of his actions were. The approach I’m describing in this post is a bit different than Greg Young describes. His solution promotes no database on the command side; a database is only needed for reporting. This is a great approach, but it makes things a bit more complex and it requires a green field project(?). The approach I’m describing can be used with a brown field application without much change to the existing architecture. In most cases you only have to add a query-side to the “old” architecture.

Why add query side DTOs?

In a traditional domain model, you will create the objects for solving domain logic, not for viewing. They have behavior rather than shape. To make domain objects more viewable, many developers use mapping between the domain model and a DTOs tailored for being displayed. This results in a lot of mapping between objects for the developer and domain models who exposes getters and setters (To learn why this is bad, do a Google search on; getters and setters are evil).

If you are using a ORM like NHibernate, you have to add getters to the domain model (and make the properties and methods virtual if you want to use lazy loading), and I think this is ok. The model is still protected against unwanted changes that can make it invalid. Every change have to happen through its command methods.

Summary

What you get from this architecture is; scalability on the read side of the application (where you normally get most load), the possibility to log all happenings in the domain model (by tracking the commands and events in the domain model), and a domain model that only have to worry about writing data, not be a transporter of data from the database to the GUI. I guarantee that this alone will make things a lot easier for you. And one final thing; creating objects (DTOs) based on the view helps us avoid a lot of mapping and a lot of requests against the database to fill the view with data. I will go through the parts of the architecture in more details in future posts.

Update: I have done a update to this figure in a new post.

image

Tags: ,

Currently rated 3.5 by 59 people

  • Currently 3.525423/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Aug 30 2009

Services

Category: DDDAdministrator @ 17:24

When starting to learn Domain Driven Design, entities and values objects are things people normally understand pretty quickly. But, when it comes to services, I feel things are a bit more unclear for many. If you ask a Domain Driven Design expert about services, you probably will get the answer; a service is something you can’t find a good place for in your domain model.

A concrete example

image

In almost every modern GUIs you use combo boxes as a way to display different choices for the user. You need a way to fill these boxes (look at the figure), but the action where you fill them doesn’t fit into your domain model in a natural way. I look at this as a service, something you need in your domain, but nothing you will force into your domain objects. In the applications I have created lately, I have often used value objects to transfer the data from the repository to the GUI through a service (follow the red arrows in the figure). You can of course create dedicated objects for this (follow the orange arrows in the figure), but I haven’t found the need for this yet.

 

Tags:

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

May 19 2009

Speaking at NNUG in Trondheim 28.05.2009

Category: NNUG | DDD | Presentation | Speakerfossmo @ 14:16

image At the next Norwegian .NET User Group meeting I’m going to talk about my experience with Domain Driven Design. I hope we can get a discussion around the topic after the talk. I’m really exited and looking forward to the meeting. Sign up for the meeting here.

Tags: ,

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Apr 21 2009

My first experience with Domain Driven Design.

Category: DDDfossmo @ 17:33

image These last months I have been learning Domain Driven Design. It’s often shorted to DDD. I have had plans to start looking into DDD for a while, but other things have always gotten in the way. I’m working as a consultant and some months ago I was assigned to a new customer, and they wanted to use DDD in their new project. Lucky for me :-)  Now I got the change to look into this DDD stuff and I must say that it will influence how I design my applications in the future.
I find this subject extremely exiting, so I have decided to write some posts about it. Some of the subjects I will cover is Ubiquitous language, Domain Model, Entities, Value objects, Services, Aggregates, Repositories, Factories, Bounded context to list some.

How to get started

I started out my DDD journey by reading some books:

Domain-Driven Design: Tackling Complexity in the Heart of Software. This book is written by Erik Evans. It’s considered the bible of DDD. I have heard people referring to it as “Lord of the rings” for developers because it uses so many references to references to references. You know; Legolas was the son of Thranduil, King of the Woodland Realm of Northern Mirkwood, son of … you get the picture? 
I use this book more as a reference, and I haven’t read it from page to page, but I have read a book which is a summary of Evans book; Domain Driven Design Quickly. It’s a good book and only a bit over 100 pages. It’s free and can be downloaded from InfoQ.

The book to blame for me learning DDD is written by Jimmy Nilssons and is called Applying Domain-Driven Design and Patterns: With Examples in C# and .NET. It’s a great book which is easy to read and he uses a lot of examples to explain the concepts in DDD. Nilsson uses TDD through the hole book to explain what DDD is. This makes it very easy from the reader to follow.

The last book I have looked into is a book written by Tim McCharty. It’s called .NET Domain-Driven Design with C#: Problem - Design - Solution (Programmer to Programmer). This book contains a lot of code. The code can be found at Codeplex. I got some hint on how to implement some of the patterns that DDD fronts from this book.

I you find videos and podcasts more easy to learn from, I can recommend listening to Alt.NET podcast show about DDD. Scott Hanselman also have a interview with Rob Conery where the topic is DDD. The last podcast I will recommend is one from Deep fried bytes. This is a conversation with David Laribee. 

If you want more links, you should go to this site. This guy have gathered some links to different DDD sources. You can also check my delicious bookmarks for updates to links.

Ubiquitous language and domain model

The first thing that pops into my mind when someone ask me about DDD is the domain model. That’s kind of obvious because we are talking about Domain Driven Design. DDD recommends that you start out by creating a domain model before you focus on anything else. Many developers would start out by focusing on the database when they create a application. This is not recommended by DDD. The reason for this is that you want to capture the domain in a model that the business person can understand. I’m referring to business person and domain expert in this post and I’m actually talking about the same person. The business person and domain expert is often the same person or at least, the business person is the product owner and should understand the domain model. You should sit down with the domain expert and try to create a shared language; the ubiquitous language. The reason for this is that you want a language that the business person and the developer understands. By doing this you will avoid many misunderstandings. What we did when starting to figure out the domain for the customer, was to get the domain experts to write down important concepts from the business we where trying to capture. We focused on using the same terms. They didn’t, for example, use the term order, but they used sale, so we called it sale in our domain model although it looked more like an order to me.  When we had talked about the terms and how the different parts of the application should fit together, we started to mold the domain. We also created some simple sketches of parts of the domain.

The nice thing with the domain model, from a developers perspective, is that the model is the code. You don’t try to model the domain with a strange notation or tool. The code is the model. The reason we can use the code as the model, is the ubiquitous language. You are capturing requirements in terms the domain experts understands. If the domain expert is a developer, this is even simpler.

I’ll try to keep these posts short and focus at one thing at a time, so I guess this is time to end this post. Next time I will explain what a entity and a value object is.

Tags:

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5