Applying Domain-Driven Design and Patterns: With Examples in C# and .NET

Author: Jimmy Nilsson
All Stack Overflow 17
This Month Stack Overflow 2


by Kyle West   2019-07-21

i agree that the model objects go into POCO. so lets say i have an Order object. My question is where do i have the class that stores a collection of orders ??

That depends on your business. Most likely you'll have a collection of orders in a few different places...

On your customer object, each customer should have a collection of orders, so you would have one there.

If you have departments, each department should have a collection of orders they created.

If you have warehouses, each warehouse may have a collection of orders they are responsible for fulfilling.

Some objects have no parent, and that's fine. In my system, we have clients. The real-world owner of the clients is us (the business), but there is no "Us" object in the system. If you're looking to get a list of your clients (in our case) we query the repository for it.

IRespoistory<Client> repository = new Repository<Client>();
IList<Client> clients = repository.GetAllClients();

The same could apply to your orders.

I'd recommend checking out this DDD book:

by anonymous   2019-07-21

Although it is not an open source project you may find some good samples in this book: "Applying Domain-Driven Design and Patterns: With Examples in C# and .NET"

by anonymous   2017-08-20

10,000 foot answer:

You might find Domain Driven Design and Clean Code useful as they give you a set of patterns that work well together and a set of principals for evaluating when to apply a pattern. DDD resources: the book, free quick intro, excellent walkthrough. Clean Code resources: summary, SOLID principles.

Specific answer:

You are already using the Repository pattern (your utility classes) which I'd probably use here as well. The static members can make the code difficult to test but otherwise aren't a problem. If the Repositories become too complex, break out the low-level API communication into Gateways.

Since an entity is split across multiple data sources, consider modelling this explicitly. For example: Person, HumanResourcesPerson, AccountingPerson. Use names understood by the external systems and their business owners (e.g. Employee, Resource). See Single Responsibilty Principle and Ubiquitous Language for some reasoning. These may be full Entities or just Data Transfer Objects (DTOs) depending on how complex they are.

The synchronization might be performed by an Application Service that coordinates the Repositories and Entities.

by anonymous   2017-08-20

For your needs I would recommend starting with:

Like the title says; it's basically a book on how to to DDD and TDD in a .NET environment.

by anonymous   2017-08-20

A good read is Jimmi Nilssons book (and blog for that matter) Applying domain driven design

It's a mixture of Evans and Fowlers books (Domain-Driven Design - Evans), and (Patterns of Enterprise Application Architecture - Fowler)