How To Implement DDD with C# .NET 4

As I'm typing this, I'm realizing that it's very hard to explain. My apologies if it's indiscernible. My end goal is to have someone with more experience look at how I'm structuring my solution and provide feedback on whether or not it is an acceptable setup.

I currently manage several small support projects that are loosely related to one another. They are all over the board. I want to create a unified INTERNAL-WEB application to manage these projects. I've managed to group everything conceptually into three domains. SHIPPING, EXTERNAL-WEB, INTERNAL-WEB. From a business perspective, SHIPPING sends WIDGETs to CUSTOMERs which then connect to EXTERNAL-WEB. The problem is that SHIPPING's definition of WIDGET and CUSTOMER is different than the EXTERNAL-WEB definition, so I need to break these two apart.

After some thinking, I've come to the conclusion that the best way to organize this in VS2010 is to create a solution and then nest multiple projects within the solution. I'm envisioning a layout like the following.

SOLUTION
---SOLUTION.SHIPPING.Domain             (Classes)
---SOLUTIO开发者_运维知识库N.SHIPPING.Infrastructure     (Classes)
---SOLUTION.EXTERNAL-WEB.Domain         (Classes)
---SOLUTION.EXTERNAL-WEB.Infrastructure (Classes)
---SOLUTION.INTERNAL-WEB.Domain         (Classes)
---SOLUTION.INTERNAL-WEB.Infrastructure (Classes)
---SOLUTION.WebUI                       (MVC3 Project)

I'll have to add additional projects for context maps and anti-corruption layers to allow communication between domains, but this is the basic layout.

Is this smart or is it stupid?

Thanks, Greg

---

How you have configured your solution has nothing to do with DDD and won't effect the success of your project. Good code that is organized badly is much better than bad code that is organized well.

Projects have a productivity and complexity cost associated with them. Right now you are agonizing over details which don't really matter.

More projects also equals slower compile times which increases context shifting. Try reading a book and pausing for 30 seconds every page.

New projects should be created for either deployment or code sharing purposes. Good reasons include if the domain is shared between two front or if you have a monstrous deployment strategy ( 1000s of machines ) and megabytes still matter.

Once you simplify the rules for new projects the decisions start to be made naturally as the codebase matures and new requirements pops up. You are essentially making physical decisions at the last possible moment. This is good. Don't BUFD this when you have features and code to write!

---

Not sure why this question is tagged MVC but the MVC codebase is pretty lean with only 1 main project. Compiles fast and is really easy to navigate around.