Domain Driven Design Approach for a Project Management System C# ASP.NET 3.5

Question

I'm writing a simple Project Management System using C# 3.0 and ASP.NET 3.5 with a SQL Server 2008 R2 backend.

At the moment it's essentially a data driven application with basic CRUD functionality, a small amount of business logic and some validation.

It's anticipated that the system will grow to contain more complex business functionality and I am interested in trying to remodel it using the principles of Domain Driven Design (DDD).

I realise this is overkill for how the system stands at the moment and I anticipate creating an anemic domain for now.

The system consists of Customers, Clients, Projects, Components and Activities.

A Customer has 0,1 or many Clients. A Client has 0,1 or many Projects A Project has 0,1 or many Components and A Component has 0,1 or many Activities.

How would I go about modelling this using DDD? Would I have Customer, Client, Project, Component and Activity as Aggregate Roots or would I have one Aggregate Root (the Customer) and have Client, Project, Component and Activity as entities accessible through Customer? Is there a recommended way of modelling many to one relationships between entities/aggregate roots?

I realise this hasn't touched on value objects (obviously Customer, Client etc contain several attributes) etc. but I am a complete beginner here and would love some pointers as much as a near complete answer.

Apologies for the open ended nature of the question, I already have a working system but am looking to the future.

Thanks, Rich.

Answer 1

The core of Domain-Driven Design is not software analysis, it's business analysis. Applying the ideas and patterns of DDD will probably have you ending up with Aggregates and Entities that won't be called Customers, Clients, Projects, Components and Activities at all.

Presupposing a given set of classes/entities and trying to enforce DDD building blocks on them may not get you anywhere soon.

To a beginner I can only recommend to (re-)read the book Domain Driven Design by Eric Evans. And not only the first few chapters, the later parts (Part III - Refactoring to Deeper Insights and Part IV - Strategic Design) are much more important than the more tactical Part II which handles the low level Building Blocks.

Update: If you just want to do a modelling exercise without the time-consuming analysis (which makes DDD so expensive and suited only to complex domains), I recommend reading Streamlined Object Modelling: Patterns, Rules, and Implementation .

Answer 2

Usually i put all this types of elements as aggregate roots, you couldn't see the future grow or changes of the model, if you shall need access to the activities as a independent entity for example to make a report of activities, group by type of activities and segmented by months and the make a subreport to explode the information by Client or customer, from this point try to make a report from customers - clients- activities is hard and sure you need to add some code to process the response and make the report.

you could think in customer a the root but don't avoid references to the parent on the childs entities, i think this is the best practice to don't have headache.