[ACCEPTED]-How to Organise a Domain Driven Design Project?-organization

I try to keep things very simple whenever 51 I can, so usually something like this works 50 for me:

Myapp.Domain - All domain specific 49 classes share this namespace

Myapp.Data - Thin 48 layer that abstracts the database from the 47 domain.

Myapp.Application - All "support 46 code", logging, shared utility code, service 45 consumers etc

Myapp.Web - The web UI

So classes 44 will be for example:

• Myapp.Domain.Sales.Order
• Myapp.Domain.Sales.Customer
• Myapp.Domain.Pricelist
• Myapp.Data.OrderManager
• Myapp.Data.CustomerManager
• Myapp.Application.Utils
• Myapp.Application.CacheTools

Etc.

The idea I try to 43 keep in mind as I go along is that the "domain" namespace 42 is what captures the actual logic of the 41 application. So what goes there is what 40 you can talk to the "domain experts" (The 39 dudes who will be using the application) about. If 38 I am coding something because of something 37 that they have mentioned, it should be in 36 the domain namespace, and whenever I code 35 something that they have not mentioned (like 34 logging, tracing errors etc) it should NOT 33 be in the domain namespace.

Because of this 32 I am also wary about making too complicated 31 object hierarchies. Ideally a somewhat simplified 30 drawing of the domain model should be intuitively 29 understandable by non-coders.

To this end 28 I don't normally start out by thinking about 27 patterns in much detail. I try to model 26 the domain as simple as I can get away with, following 25 just standard object-oriented design guidelines. What 24 needs to be an object? How are they related?

DDD 23 in my mind is about handling complex software, but 22 if your software is not itself very complex 21 to begin with you could easily end up in 20 a situation where the DDD way of doing things 19 adds complexity rather than removes it.

Once 18 you have a certain level of complexity in 17 your model you will start to see how certain 16 things should be organised, and then you 15 will know which patterns to use, which classes 14 are aggregates etc.

In my example, Myapp.Domain.Sales.Order 13 would be an aggregate root in the sense 12 that when it is instanced it will likely 11 contain other objects, such as a customer 10 object and collection of order lines, and 9 you would only access the order lines for 8 that particular order through the order 7 object.

However, in order to keep things 6 simple, I would not have a "master" object 5 that only contains everything else and has 4 no other purpose, so the order class will 3 itself have values and properties that are 2 useful in the application.

So I will reference 1 things like:

Myapp.Domain.Sales.Order.TotalCost

Myapp.Domain.Sales.Order.OrderDate

Myapp.Domain.Sales.Order.Customer.PreferredInvoiceMethod

Myapp.Domain.Sales.Order.Customer.Address.Zip

etc.

I like having the domain in the root namespace 14 of the application, in its own assembly:

Acme.Core.dll [root 13 namespace: Acme]

This neatly represents the fact 12 that the domain is in scope of all other 11 portions of the application. (For more, see 10 The Onion Architecture by Jeffrey Palermo).

Next, I have a data 9 assembly (usually with NHibernate) that maps the domain 8 objects to the database. This layer implements 7 repository and service interfaces:

Acme.Data.dll [root 6 namespace: Acme.Data]

Then, I have a presentation 5 assembly declaring elements of my UI-pattern-of-choice:

Acme.Presentation.dll [root 4 namespace: Acme.Presentation]

Finally, there is the UI project 3 (assuming a web app here). This is where 2 the composition of the elements in preceding 1 layers takes place:

Acme.Web [root namespace: Acme.Web]

Although you're also a .Net developer, the 15 Java implementation reference of the cargo app from DDD by Eric Evans and Citerus is a 14 good resource.

In the doc'd code, you can 13 see the DDD-organization into bounded contexts 12 and aggregates in action, right in the Java 11 packages.

Additionally, you might consider 10 Billy McCafferty's Sharp Architecture. It's an ASP.Net MVC, NHibernate/Fluent 9 NHibernate implementation that is built 8 with DDD in mind.

Admittedly, you will still 7 need to apply a folder/namespace solution 6 to provide the contexts. But, couple the 5 Evans approach with #Arch and you should 4 be well on your way.

Let us know what you 3 are going with. I am on the same path as 2 well, and not far from you!

Happy coding,

Kurt 1 Johnson

Your domain probably have a name, so you 5 should use this name as namespace.

I usally 4 put repository implementation and data 3 access details in a namespace called Persistance 2 under the domain namespace.

The application 1 use its own name as namespace.

I'd check out codecampserver since the setup 15 there is quite common.

They have a core project 14 in which they include both the application 13 and domain layers. I.e. the insides of the 12 onion (http://jeffreypalermo.com/blog/the-onion-architecture-part-1/).

I actually like to break the core 11 apart into separate projects to control 10 the direction of dependency. So typically 9 I have:

MyNamespace.SomethingWeb <-- multiple 8 UIs
MyNamespace.ExtranetWeb <-- multiple 7 UIs

MyNamespace.Application <-- Evans' application 6 layer with classes like CustomerService
MyNamespace.Domain 5

• MyNamespace.Domain.Model <-- entities
• MyNamespace.Domain.Services <-- doman services
• MyNamespace.Domain.Repositories

MyNamespace.Infrastructure <-- repo implementation 4 etc.

MyNamespace.Common <-- A project 3 which all other projects have a dependency 2 to which has things like a Logger, Util 1 classes, etc.