Posts tagged architecture
What is CRUD?
Aug 30th
Quite often we see criticism of Create-Read-Update-Delete solutions. There are tons of blog posts why CRUD is inferior to Domain-Driven Design. I have probably written a few of them in my life. It seems like everybody is doing proper DDD and advocating doing it so where’s the problem? I haven’t seen so many domain driven systems in the wild. If you take a look at DDD tag on StackOverflow you’ll see that most of questions are actually concerned with CRUD, not DDD solutions. So what is this CRUD?
It is an architectural style where the centre of the solution (or the lowest layer, depending on your perspective) is a package containing structures that represent data in the real world. These structures are usually mapped one-to-one to database tables using some kind of Object-Relational Mapper (NHibernate, remember?). Upper layers contain stateless service classes that operate on these structures.
Modern CRUD architectures borrow much of the terminology from Domain-Driven Design which confuses many people. You can find entities (a fancy name for a data structure), repositories (another fancy name, this time for Data Access Object pattern), domain services (place where the logic lives in CRUD) and so on. Please bear in mind that in the rest of this post I will be using these terms in context (and meaning) of CRUD, not DDD.
So, is CRUD inferior to Domain-Driven Design, like I suggested at the beginning? Not really. It has different architectural properties. It probably doesn’t scale as well when complexity grows. CRUD earned it’s really bad opinion because it can become quite messy if you don’t understand it’s essence.
And the essence of CRUD is Create-Read-Update-Delete. Period. You can do these four and only these forur operations on any entity. As you can see, there is no support in the architecture for establishing one-to-many relations. To be precise, there is no support for entities having collections of other entities. Why? Suppose you have a Parent entity that contains a list of Child entities. If you add a new Child entity to the collection, what should happen? It could be translated as “Update the Parent, Create a Child and AddRelation between Parent and Child” but also could be translated as “AddRelation between Parent and Child”. There is no language in CRUD to define logical relations between entities (like in DDD between aggregate root, entities and value objects) that can help to deal with such ambiguities.
What you can do is stick to many-to-one side of relations if you need them. Looking from Child’s perspective, the aforementioned operation would be unambiguously translated to “Create Child” if child entity doesn’t exist yet or “Read Child, Update Child” otherwise. The reference to it’s parent is part of it’s definition so Update operation can deal with it. But what if you need to get a collection of children of some entity? You can always use repository to query the data source, right?
To sum up, if you happen to build a simple system, please don’t throw DDD at it. It would be both an overkill and a mess. Remember, CRUD can be you friend if you understand it’s rules and follow them. Don’t try to make it DDD-Lite.
WCF, you are doing it wrong!
Aug 26th
If you are using WCF directly you are probably doing it wrong. Yes, I mean it. If you implement your service in one huge class you are doing it horribly wrong. Let me explain why.
Such a class is a violation of Single Responsibility Principle. The service class is doing few, usually completely different, things because so called service operations usually have little in common. That manifest itself in very low cohesion — often times the only field of the class that is used by more than one method is called log (or _log, depending on your conventions). Because each of these methods usually need 2-3 collaborating objects to achieve its goal, our service class ends with dozen or move dependencies. Does anything of this sounds like a good design practice? I don’t think so.
There is also another aspect of having huge service classes with many methods (called operations in WCF lingo). We don’t see messages. Instead, we have methods with parameters and return values. While this makes novice developers feel comfortable (no new stuff to learn), it makes some advanced things like request validation, automated logging, establishing processing context (e.g. opening NHibernate session) much more complicated.
Solution is really simple. Actually, there are two
- use Davy Brion’s Agatha framework
- write something similar yourself
No matter which way you choose, the goal is clear – you should not program directly against faulty WCF API. Instead, you should define concepts like
- messages (requests and responses)
- validators (ensure request is valid)
- filters (do some action before and after request is handled)
- handlers (do actual stuff)
and have some generic piece of code that handles translation of these to WCF primitives that sit under the hood. I wrote one myself and it took me less than a day. It’s really easy.
On the Repository pattern
Aug 23rd
The Repository pattern is one of the most popular patterns of enterprise application architecture (P of EAE, a great book by Martin Fowler). The pattern was further refined in context of Domain-Driven Design by Eric Evans. Since then wars has been waged around how to implement a Repository and when to use it. Here’s my take on this subject.
First of all, Fowler’s definition of Repository
Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects
should not be treated literally. Providing a collection-like interface for relational database can be a problem much bigger than posed by most of the ‘enterprise’ systems that are being built today here and there. I would suggest a more practical ‘working’ definition like this one
- Provides access methods to domain objects
- It is meant to be used by command handlers
- Returns one object or throws exception
- If it is designed to work with Unit of Work, has no Save method. Otherwise, it has
- The interface is placed in same assembly as domain model classes
The first line is pretty obvious, right? The second could be more problematic. In my opinion the very reason why we create repositories (and I do believe we should do it) is the ability to write more explicit code in command handlers (or whatever approach you use in Application layer). There are, however, cases where repositories can be useful outside of command handlers. When employing the classic approach to DDD (synchronous, without CQRS, EventSourcing and other cool stuff) we often have to display a domain object on screen. In such case we can use a repository to retrieve our object. It’s not a deadly sin son, I forgive you.
Returns one object or throws exception… Why? Because we don’t invoke any action on a collection of domain objects. Ever. If you want to display a grid, please create a separate class (I would call it Finder) for this purpose. I am pretty sure you don’t want to display all the data associated with a domain object on a grid, so your finder will probably retrieve only a subset of information. If you need the data only for display purposes, it can be a little bit stale, so you can add caching. If I haven’t convince you yet, think about change management. Do you really want to change your repository (which is part of Domain Model) every time you add a column on a grid on some UI form? I bet no. So please place all the finder methods outside of the repository.
But what if you want to invoke an action (change state) on a collection of object? The answer is simple. You are probably missing a real-world domain object which corresponds to this collection and should be the sole owner of the piece of data you want to change. Find that object and model it explicitly in your solution.
Because I don’t want to start flame wars about using (or not using, or abusing) Unit of Work, I try to be as neutral as possible in this matter. If you want Unit of Work, it’s OK for me, but please be as kind to remove Save methods from repositories. And if you don’t know if you wan’t to use Unit of Work or not, think if there is a chance that one of the repositories will ever be implemented using anything else than your favourite ORM (which is of course NHibernate). If so, don’t use Unit of Work because it’s abstraction will break on this one repository and so will your whole beautiful architecture.
The last line is, again, pretty obvious. Repositories are part of the Domain Model so, despite the fact they are not going to be used by domain objects, they need to be put in the same assembly to maintain logical cohesion.
I hope you enjoyed my subjective view of Repository as a pattern in Domain-Drive Design. I can’t wait to hear your opinions.
Composing a multi-target application
Aug 11th
The project I have been working on recently used to simple application with only two executables, a WCF service and a MVC frontend. People who worked on this project before introduced Unity as inversion of control container. To my surprise, despite using Unity, the rest of IoC infrastructure was quite decent. There was a special Composition Root project shared between WCF and MVC that configured the container with all the dependencies shared by both projects. There was no duplication with regards to IoC-related code.
Then new requirements started coming. After few weeks we ended up having a total of 15 executables, most of them being small utility console applications. Each application used only small part of solution’s components. Making each of them reference our composition root would be an overkill as I would have to ship each and every dll with these small apps.
Forgive me this lengthy preface. I just wanted to set the stage. As you certainly know right now, the problem is how should you structure the composition root so that it can be reused no only as a whole, but also in parts. I don’t suggest you should all use this solution. It is rather ‘I used this approach, what do you all think?’ kind of post.
The idea is not new in IoC container world. Just split the composition root into parts. Some good containers support this out of the box (e.g. Windsor’s installers, Autofac modules). Unfortunately Unity does not, so I had to implement it myself. That was easy. The hard problem was to decide where to put these little composition root parts. There are a couple of options, including:
- Putting them all in one projects. This does not make any sense since because the very reason for having them was not to have to reference all the unneeded components in executables
- Putting them in the same project as components they are responsible for
- For each ‘normal’ project create a composition project that would now how to configure the container with it’s ‘parent project’’s dependencies
I’ve chosen the second solution. As you know, it requires referencing the container assembly from each project. Although Mark rightly warned me that thar be dragons, I decided that I will trust our project team to not disturb these dragons. This means, thou shalt not use container in any other than composition root piece of code. Period. Time will show if my faith in people was justified.
The last piece of puzzle is adding relations between composition root parts. Because I am lazy, I don’t want to specify each part I want to use. I want my composition engine to figure out that if I need reference data repositories, it should also compose in reference data session factory (we’re using NHibernate). So I added a GetDependencies method to my composition root part interface. With that in place, the composition engine can calculate a transitive closure of dependencies given only the top level ones (like the repository component) and then execute all composition root parts to configure the container. Easy, isn’t it?
Now, what do you think?
Just an idea
Feb 3rd
Traditionally web applications are built using some sort of server-side framework like Rails or ASP.NET MVC. Such a framework provide means to implement business logic in a (hopefully) testable manner. Traditionally there are two approaches to shape this logic. One is to leave it close to the UI layer, probably in the Controller part of MVC pattern. The other, advocated by most Domain-Driven Design junkies, is to move it to The Model and leave Controllers as dumb as possible. As you probably already know, I am a proponent of the latter approach. Making Controllers dumb led me to an idea: how about getting rid of the controller and the web framework they are living in and letting client-side JavaScript communicate directly with the domain? Just an idea…
Draft solution
In traditionally approaches where domain entities are moved up and down through all the layers (and almost all tiers) it would be difficult to use them also on client side. That is why we are going to use CQRS as our architectural principle. The first draft solution would look like this:
Client-side JavaScript code is reacting on user input and building commands which are asynchronously sent to the remote facade sitting on the application server. Simple, isn’t it? Is has some drawbacks though.
Problems
First is that client has no means to inspect the outcome of the commands he is sending. He has to duplicate the read model code in order to update the UI widgets. Second, the commands are immediately executed upon reception by the Remote Facade and their outcome is persisted in the Event Store. If a user clicked a wrong button, it would be difficult to undo his action.
Solution, refined
How can we solve this problems? One solution that comes to my mind is to not persist command execution outcome to the event store and read model, but create an in-memory representation of updates to the read model and sent it back to the client. There is no state change on server side. Client can submit commands as user interacts with the UI and receive back the outcome in a denormalized form which can be directly and immediately bound to the UI widgets. All the commands are recorded on client side. The following diagram depicts this process.
When user wants to accept the changes he made, all the recorded commands are send to the server for ‘persistent’ execution.
Challenges
Looks nice, isn’t it? There are some challenges though. There is a lot of JavaScript code to be written to make the client-side plumbing work. There are also some design questions that need to be answered. For example, how do we specify which changes in a read model the client is interested in? Do we send all the changes or somehow ’subscribe’ for particular views in the read model? And how do we create denormalizers so that the same code can be run against both persistent and in-memory read models? We probably need a library for abstracting the read model storage implementation from the denormalizer code. These are hard problems, but I think they are worth solving. The final outcome could be very, very nice.
And it is worth notice that this approach is not limited to the thin client (JavaScript). The same architectural principles should be valid in case of both Silverlight and WPF client.
