Click here to Skip to main content
15,075,944 members
Articles / All Topics
Technical Blog
Posted 28 Jan 2015

Tagged as


1 bookmarked

Domain Driven Design App Structure - Part 2

Rate me:
Please Sign up or sign in to vote.
4.00/5 (1 vote)
28 Jan 2015CPOL2 min read
Domain Driven Design App Structure - Part 2

In my previous post, I gave an overview of what an implementation of a Domain Driven Design Application might look like.

I will be running a C# project in parallel with my Practical Domain Driven Design Articles. The plan is to eventually provide a full project template that can be used either as a DDD reference project or as a starting point for a new application. You can find the SimpleDDD project on GitHub.

Kicking off SimpleDDD

If you have not read my previous post, go do that first as this will give you some context.

Opening the project, you will find an application folder with 4 projects inside. I have named these projects a bit different than in my previous post. Exact names for these layers are not important, they should just be named clearly.


  • This is our Domain/Model layer
  • It can also be called Core if you like
  • It depends on no other projects in our solution


  • This is our Persistence Layer
  • This layer will probably get renamed later to indicate the technology used. For example SimpleDDD.Data.EntityFramework
  • It depends on SimpleDDD.Domain


  • Our integration layer (duh)
  • Depends on SimpleDDD.Domain


  • This is our Application layer
  • I have gone back and forth a few times on what this should be called. It is fine to call it Application or App or even AppBoundary. If you have a really big system, it can even be named after your Bounded Context. I find that API provides a nice naming convention. I prefer something like UserApi over UserApplicationService.
  • It depends on all three other projects.
  • It is the project that will get used by consumers.

You will see that I have not added any consuming projects like a console app. We will do so later on when we talk about boundaries, DI and object lifetimes.

I have also cleared out all unused references added by Visual Studio. This might seem a bit redundant but we want to maintain a clean, fast compiling solution, thus we will stick to good principles from the start.

This article was originally posted at


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Software Developer (Senior)
I write about Domain Driven Design, Clean Code and .net

Comments and Discussions

-- There are no messages in this forum --