design patterns - Should I use separate projects for bounded contexts in DDD .NET? -

we discussing how implement domain driven design.

are there immediate drawbacks using separate project each bounded context?

all thoughts , suggestions on our approach welcome.

so like:

- projecta.dll (user context web service)     - references          - projectb.dll  - projectb.dll (user context domain)  - projectc (web app)     - references         - projectd.dll         - rest calls projecta user stuff  - projectd.dll (product context domain)  - projecte.dll (some other context)     - domain         - service             - iservice.cs         - dto             - dto a.cs         - entity             - entity a.cs             - entity b.cs     - repository         - repo.edmx 

we considering making bounded contexts accessible via web services allow scalability of areas heavy traffic.

the answer question not straight-forward may appear. because there different ways integrate bcs.

this question (and answer) summarize problem pretty well:

one approach consider whole application bc, , other consider domain logic bc.

to answer question, have differentiate between two.

case 1: bc manifests whole application

this scenario typically have 1 development team per application (and bc extension). consequently, suitable vs solution , project setup create 1 solution per application, , structure projects according logical layering.

case 2: bc manifests domain logic library

here, make sense put in 1 solution if overall application not big. otherwise, extract supporting bcs own solution required. driven team organization.

---

to apply case, think suggestion starting point. if solution grows big, later take user stuff out , move dedicated solution. the important thing here have well-defined bc borders , interfaces. that, easier move stuff later.