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.