I wanted to write a serious of posts about using of DDD in Sharepoint from a long time ago, but because of lacking of time and very tight schedule during last months can do it only now. I used DDD before to start working with Sharepoint – in ASP.Net and win forms applications. Currently I also have wide Sharepoint development and architecture design experience, including using of DDD in large Sharepoint projects. But of course I worked not only with DDD, so I can compare various approaches using my own real-life experience. Hope this reading will be useful and interesting for you.
This material will be useful mostly for developers who is working on medium and large projects, who understands the business-value which brings DDD. If you need quickly develop a web part which displays data from some storage, it will be overengineering most probably. But if your goal is to build solid and maintainable architecture for the system which supposed to be used for years, then it will be helpful. This part of the serious won’t contain any code examples. I will try to answer why and when you should use DDD. In the next parts, I will describe key technical solutions which can be used in practice. Let’s start with brief introduction to DDD and where we should use it and where not.
In Sharepoint you may manipulate data by several ways: you may work with SPListItems, OTB Content by query web part, Data view web part, BCS, external content types, etc. The advantage of this approach is that all of these comes out of the box and you may start using it very fast. But this approach has significant disadvantage: it hides business domain model from developers. SPListItem may represent OrderItem, Product, Checkout transaction and so on, it can represent anything. When you will read code which operates by list items you won’t immediately see what it does in business domain. Also code won’t reflect ubiquitous language: common language for all team members including developers and business people. As result code became less clear, it is harder to understand it, which in turn leads to more bugs and confusions. It will be hard to change it in future. Business rules are not static: in modern world business should be able to change very quickly for versatile market conditions. If your software won’t reflect business needs and won’t be ready for changes, customers will choose another vendor (one of the projects which I worked on, was the project from another vendor. The code was written using approach described in this paragraph. But it caused so many problems, so finally business decision was made and customers changed the vendor).
Another way to work with data is to build clean business model using POCO (or at least generated by automatic tools like in Linq 2 Sql) and build infrastructure for working with them by yourself. With this approach developers will write code in terms of business domain. They will manipulate by Products, Orders, Overdraw limits, etc, etc. – e.g. by terms which are understandable by business people. Yes it requires more work from you on initial phase, because you need to add extra layer on top of raw SPQuery and SPListItemCollection. Instead of using OTB CQWP you will need to create custom web part which uses repository in order to retrieve objects from storage, then convert them into view model (this step is optional) and pass to the view, which will render it for users in appropriate form. This approach follows DDD style. Although in Sharepoint you may need to combine DDD infrastructure with OTB web parts – it will allow you to decrease implementation time which may be crucial for business. This approach also works. You just need to remember that core of your application anyway should be expressed via clear domain model.
Whether you will use DDD or not I highly recommend to read Domain-Driven Design by Eric Evans or at least Domain Driven Design Quickly, if you don’t have time to read Evan’s book. I always recommend it for all developers, regardless of the technology stack or programming languages they use. Yes, I don’t ask members of my Sharepoint team to read books about Sharepoint workflows, search, BCS, web parts and other technical stuff in their free time. In most cases in order to start using them and bring value for business immediately it is enough to have some background and turn on your head (e.g. I get this background by reading blogs of developers – the same developers as I am). It is impossible to know everything, that’s why instead of reading such books, it is better to teach yourself to quickly teach any technology, but it is too philosophical and too far from current article’s subject :). Probably I will write something about it in future.
Of course there is no direct answer where to use 1st approach and where DDD-style approach. You still have to evaluate all pros and cons and make decision by yourself and take this responsibility. As any other paradigm, framework, technology – it should help you, not prevent from making things efficiently. If for supporting of DDD infrastructure you need more time than for implementing actual business tasks, probably you should re-consider it.
Personally I prefer DDD approach for most of my projects: but I work mostly with medium and large projects (starting from 2-3 man years). 4 last projects where we used DDD were successful: they were implemented in time without major problems and within budget (almost :) ). 1 large project which we got from another vendor tried to use DDD but only in one part of the functionality (say 25% of whole functionality): this project was not very successful. The reason is not only in DDD of course (main reason of success is great team and each member’s attitude, because as said Jim McCarthy in his book Software for Your Head: team = product), but from my point of view it was important success factor. I added exact digits here in order to give you ability to reference me when you will argument using of DDD for your chief :). Probably it will add some weight to your scalepan.
Another reason is more psychological: you will make your work better if you enjoy it. I enjoy working with clean model without infrastructural noise, and I use it not only in Sharepoint of course. I use it in ASP.Net MVC, web forms (yes, yes), win forms, python projects. People reading this code said that they really like it and will use it in their own projects (to be honest I heard only one negative response from the apologist of single static class on thousand lines of code. But as he was not from my team I didn’t try to argue with him. I have more useful things to do). From other side when I need to work with code for maintenance from another company where I see SPListItems, TaxonomyFieldValues, SPQuery, etc. applied without business model layer, I fill very uncomfortable. Also it makes me think why customers stopped working with vendor who created this code.
This was brief philosophical introduction to the DDD in Sharepoint. Hope it was not very boring. Promise that next parts will be more practical and will have a lot of code examples.
