Implementing With Domain-Driven Design from the Ground Up

by Jan Stenberg on Oct 30, 2013 |

The domain describes your business; it is a collection of concepts and logic that drive your enterprise. If you follow this essence of Domain-Driven Design, (DDD), then the domain will be the most important ingredient of the application, Andras Nemes, a Swedish web developer on the .NET platform, explains in the first in a series of ten blog posts on building a web service on the .NET platform, based on Domain-Driven Design principles.

In a technology-driven approach it can easily happen that choices affect the domain. In DDD the direction is reversed, the domain is the most important ingredient of the application and technology will become implementation details where the exact implementation can vary. And that is how it should be, Andras believes, your domain is an independent entity that reacts to business requirements and changes in the domain may affect the technology chosen.

Andras clearly states that his goal is not to cover all details and aspects of DDD, for that he refers to the original DDD book by Eric Evans. Instead he wants to build the skeleton of a .NET solution that takes the most important ideas from DDD and hopefully can become a base for projects based on DDD. His ambition though is that also developers completely new to DDD can benefit, for that he has provided explanations for all key concepts he uses.

His goal is a solution with the following layers:

  • Infrastructure: infrastructure services to accommodate cross-cutting concerns.
  • Repository: data access and persistence technology layer.
  • Domain: the domain layer with business entities and logic, the centre of the application.
  • Application services: a thin layer providing actions for the consumers.
  • Web: the consumer of the application.

Starting his tour through DDD, Andras explains some of the main tactical concepts in DDD, e.g. entities, value objects and aggregates, together with some guidelines for usage. He then spends the rest of his series of posts creating each of the layers that ultimately constitute the application.

Andras final conclusion is that DDD has helped him reduce the tight coupling often found in more traditional layered solutions, with the domain layer now the centre of the application. He has also managed to hide the most technology-driven layer, the repository implementation, behind an abstraction that can be replaced.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

General Feedback
Marketing and all content copyright © 2006-2016 C4Media Inc. hosted at Contegix, the best ISP we've ever worked with.
Privacy policy

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.