Where should domain objects and service class objects be located?

Question

I'm doing my best to learn DDD, but I'm unsure about some really basic concepts; Where are your domain objects and services located, and how is the overall layout organized? I have a habit, good or bad I don't know, that's why I ask; to make a "Program" class, which holds domain collections, domain objects and service objects. Like example below.

Is this a good or bad approach? And if bad, what are alternatives? I'm so far just working with winforms projects, so that's my main concern at this time.

Also if you could include some evaluation of my use of "static" objects here? I'm often unsure if to use static, and tend to just throw it on if I know it's a singleton object (if that's the correct term).

EDIT: To explain a bit more, I'm using the New method of the "Program" class to coordinate the different domain objects, and run initial loading from database etc, on program startup. So if you suggest me to get rid of this class, then should I introduce some other services instead to deal with program startup?

Example:

class Form1
{
    private MainClass main;
}

class MainClass
{
    public static UserService UserServ;
    public static UserAccountService UserAccServ;
    public static List<UserAccount> UserAccounts; 
}

class UserService
{
}

class UserAccountService
{
}

class UserAccount
{
    public UserData User;
}

class UserData
{
}

---

EDIT: Response to David:

Thanks! To address your points:

1) My example was just a rough type, I do use separate files for each class, and my project is in fact already 10,000 lines of code, although it may not sound like it.

2) Understood tips on interfaces.

3) Understood about assembleys.

4) I'm using Repositories (and FluentNHibernate), I plan to have services depend on them yes. At the moment I have xxxManager classes, which I know is bad, and will work to change them to xxxServices.

5) I understand DI is very popular, and it's good you make this point, so I know this is a key resolve for my question. I will be learning that. So as far as I understand, you suggest me to inject the services directly to the form class? But what about domain objects? Where do they "live"? Should they all live in some type of service? If that's the case, what type of services do you create to deal with program-startup logic? I understand the basic concepts of services for persisting data, using repositories etc, but there are probably other type of common service classes that I'm not aware of, related to my question?

PS: I should not have (mistake) named my class "Program", as this is already a class in C# projects. I use both C# and VB, so actually in C# I usually call it MainClass. So I edited this.

Answer 1

What you are describing is how to organise your dependencies (in this case, your forms project depends on the services).

A few points about the above code:

• It looks like you have all of your classes in the same file. Generally you should place every new class in its own file.
• Your service classes should both implement an interface (IUserService and IUserAccountService) - this enables you to mock your dependencies for unit tests, to swap implementations and to better decouple your application.
• Your service classes should ideally be in a different assembly (new visual studio project), as should your domain entities (UserAccount and UserData).
• You might consider creating one or more repositories to deal with simply getting the data to your application services (application services would have a dependency on the repository, the repository would not depend on the service).
• You have your services in static fields (not a singleton, that is a pattern which uses static fields in C# to ensure that exactly one object will be created for the lifespan of the application). It would be better for you to use DI (see below) instead of your forms using Program.UserService...etc.

Once that's done then you're in a position where you can look at using dependency injection (DI) to provide your services to your application (as opposed to your application being responsible for creating them itself). Ninject would be a good choice to use. Here's an example of how to implement it but you might have more luck on the Ninject wiki.

Answer 2

With domain-driven design it is common to have a solution with three projects; Application, Domain, and Infrastructure.

The Application layer contains your Windows Forms application and things related to your user interface, it contains the Program.cs file.

The Domain layer contains the root aggregate, related domain entities attached to the root aggregate and the domain events. Also contains interfaces for your repositories.

The Infrastructure layer contains NHibernate and your repositories.