I'm working on reorganizing a .NET solution with 65 different projects, this includes multiple web projects for different products.
I'm looking at doing something like this...
Company.Domain
Company.Repository
Company.Services (where services = business logic)
...etc. etc.
My question is, what are your thoughts on the Company.Services project getting too big with many nested namespaces { i .e. Workflow, SharePoint, Clinical, etc. etc. }
Would it be better to have a different assembly for each service area?
Company.Services.Workflow
Company.Services.SharePoint
Company.Services.Clinical
... etc. etc.
My thoughts are that breaking each service layer out into its own assembly would create an excessive amount of projects. But I also have concerns that having one services assembly could get pretty big.
First of all, splitting up the project into more assemblies increases compile time and maintenance efforts. So don't just split because you can do it. Split where you want to isolate concepts.
Then again, splitting a project into assemblies helps to understand and reify the dependencies. For example you can't have circular dependencies between projects, whereas nothing stops you from having circular dependencies within a single project. Those circular dependencies can be an indication of a flaw in your design.
Another thing: if you split, try to think how you split - "vertically" or "horizontally". Consider an application consisting of multiple sub-domains like Sales, CRM and ERP.
Vertically: isolate layers into assemblies. Having all repositories in one assembly, all domain logic in another and all services in a third assembly certainly helps to understand dependencies as I mentioned above. But this means that you spread every isolated domain in your system across all assemblies. Ie. every assembly contains logic needed by Sales, CRM, ERP.
Horizontally: isolate domains/domain-parts into assemblies. E.g. put everything related to sales in one assembly, everything related to CRM in another, everything related to ERP in a third etc. Concepts that all those assemblies need or that need to be shared across them are moved to infrastructure projects. This approach helps to isolate functionality.
You can combine both strategies and that's what you're suggesting:
Company.Services.Workflow
Company.Services.SharePoint
Company.Services.Clinical
"Company.Services" is a vertical split, whereas I think ".Workflow", ".SharePoint", ".Clinical" are horizontal splits. That can easily lead to a massive amount of projects, basically NxM, where N is the number of layers and M is the number of domains. I'd be careful with that.
Personally I like to split vertically, isolating (sub-)domain into projects, and to move infrastructure/shared concepts to their own projects.
This approach supports reuse and configurable product lines where different clients receive different configurations of the project.
The infrastructure projects can be reused by other projects, which is nice. And the sub-domain projects can be combined as needed to form a full application. For example, only deploy the CRM module if the application needs CRM functionality.
A concrete example, I have a larger project consisting of:
Infrastructure:
Domains:
NB: There can be dependencies between domain projects, e.g. the Sales module uses things from CRM.
As a final note: again, don't split for spitting's sake. It makes most sense if the project is large enough and you have certain requirements (reusability, configurability...).