How to Organise a Domain Driven Design Project?

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

I try to keep things very simple whenever I can, so usually something like this works for me: Myapp. Domain - All domain specific classes share this namespace Myapp. Data - Thin layer that abstracts the database from the domain.Myapp.

Application - All "support code", logging, shared utility code, service consumers etc Myapp. Web - The web UI So classes 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 keep in mind as I go along is that the "domain" namespace is what captures the actual logic of the application. So what goes there is what you can talk to the "domain experts" (The dudes who will be using the application) about. If I am coding something because of something that they have mentioned, it should be in the domain namespace, and whenever I code something that they have not mentioned (like logging, tracing errors etc) it should NOT be in the domain namespace.

Because of this I am also wary about making too complicated object hierarchies. Ideally a somewhat simplified drawing of the domain model should be intuitively understandable by non-coders. To this end I don't normally start out by thinking about patterns in much detail.

I try to model the domain as simple as I can get away with, following just standard object-oriented design guidelines. What needs to be an object? How are they related?

DDD in my mind is about handling complex software, but if your software is not itself very complex to begin with you could easily end up in a situation where the DDD way of doing things adds complexity rather than removes it. Once you have a certain level of complexity in your model you will start to see how certain things should be organised, and then you will know which patterns to use, which classes are aggregates etc. In my example, Myapp.Domain.Sales. Order would be an aggregate root in the sense that when it is instanced it will likely contain other objects, such as a customer object and collection of order lines, and you would only access the order lines for that particular order through the order object.

However, in order to keep things simple, I would not have a "master" object that only contains everything else and has no other purpose, so the order class will itself have values and properties that are useful in the application. So I will reference 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.

So when you reference your Order object you have to do it like: Myapp.Domain.Sales.Order. Order? – Th3Fix3r Feb 10 '09 at 1:27 Yes and no - I extended my example a little, as the comments section is a bit too short.

– Console Feb 10 '09 at 10:00.

I like having the domain in the root namespace of the application, in its own assembly: Acme.Core. Dll root namespace: Acme This neatly represents the fact that the domain is in scope of all other portions of the application. (For more, see The Onion Architecture by Jeffrey Palermo).

Next, I have a data assembly (usually with Nbernate) that maps the domain objects to the database. This layer implements repository and service interfaces: Acme.Data. Dll root namespace: Acme.

Data Then, I have a presentation assembly declaring elements of my UI-pattern-of-choice: Acme.Presentation. Dll root namespace: Acme. Presentation Finally, there is the UI project (assuming a web app here).

This is where the composition of the elements in preceding layers takes place: Acme. Web root namespace: Acme.Web.

Although you're also a . Net developer, the Java implementation reference of the cargo app from DDD by Eric Evans and Citerus is a good resource. In the doc'd code, you can see the DDD-organization into bounded contexts and aggregates in action, right in the Java packages.

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

Admittedly, you will still need to apply a folder/namespace solution to provide the contexts. But, couple the Evans approach with #Arch and you should be well on your way. Let us know what you are going with.

I am on the same path as well, and not far from you! Happy coding, Kurt Johnson.

UPDATE: I should add that the Who-Can-Help-Me (WCHM) fork of Sharp Architecture. As of September 2010, the WCHM maintainers have been included on the contributor team for Sharp. WCHM reorganizes the Sharp Visual Studio project into Solution folders which explicitly refer to DDD concepts.

There are folders for domain (Domain and domain-specific Infrastructure), presentation (web views and web controllers), framework (code considered reusable across domains, and a services layer (Tasks). Future versions of Sharp Architecture are expected to reflect this approach. – Kurt Johnson Nov 4 '10 at 15:25.

Your domain probably have a name, so you should use this name as namespace. I usally put repository implementation and data access details in a namespace called Persistance under the domain namespace. The application use its own name as namespace.

I'd check out codecampserver since the setup there is quite common. They have a core project in which they include both the application and domain layers. I.e.

The insides of the onion (jeffreypalermo.com/blog/the-onion-archit...). I actually like to break the core apart into separate projects to control the direction of dependency. So typically I have: MyNamespace.

SomethingWeb Domain MyNamespace.Domain. Model Repositories MyNamespace. Infrastructure.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.