If you have looked into DDD (Domain Driven Design) you may find yourself intimidated by the idea of moving to a full DDD approach on your projects. Like many other people, you might find the amount of work and collaboration that must go into creating a process that allows for business and development to come together for recurring Domain Modeling exercises (meetings where you discuss and develop a conceptual Domain Model and Ubiquitous language) to be an intimidating practice to try and bring to your projects. You may have also read or heard that moving to a Domain Model pattern (Fowler) without taking on the DDD Domain Modeling process is a recipe for failure as you will miss out on many of the benefits of DDD. This can leave you following more of procedural approach in your domain like using fat Domain Services or Repositories with an Anemic Domain Model mapped to the database by your ORM. In this session we will take a look at some of the immediate benefits you can gain from using a Domain Model pattern for your Business Logic and I’ll argue that the value add would be justified with or without the DDD Domain Modeling process. We will take a look at the many practical benefits of combining OOD with your ORM to create well structured, easily persisted Domain Model. If time permits we will also take a quick look at how we can improve our code organization even more by adding CQS to the mix. For the examples in the session we will use Structure Map, AutoMapper, ASP.Net Web API and NHibernate.
Ryan Vice is an independent consultant with 12 years of experience building enterprise solutions using Microsoft technologies. He’s an MSDN Moderator, has been Microsoft MVP for Connected Systems since 2010 and his first book, “MVVM Survival Guide” was published in November of 2012. His areas of focus are software quality, increasing developer productivity and architecture best practices.