I recently joined a small software development company (servicing small-medium businesses in the aged care industry) to work on a rewrite of their software in .NET.
They had a Microsoft consultant lay out a solution framework for them as a starting point based on latest best practice, however the consultant is no longer around and the 3 of us are left with the solution now trying to decide how to proceed. It's early on in development and the architecture can change at our discretion,
One of my concerns is the modular approach. I know modular is all the rage and it has some tangible benefits, but the downside for us is an unnecessarily elaborate system. Basically every screen in every module has it's own C# project, and another project prefixed with .Domain, and if we add unit tests the projects will be doubled with .Tests, leading to around 100 projects eg.:
My question is, what are the other benefits of this modular approach? Do the benefits outweigh the architectural bloat it causes?
Furthermore, is it appropriate that the Domain be split into modules which directly match the UI modules? I thought Domain represented the business model , and modularization of the interface was a UI level concern.
My preference is to recommend to the team that we drastically simplify the solution to 3-4 projects (perhaps MyCompany.UI, MyCompany.Domain, MyCompany.Data access, later MyCompany.Tests) but I would like to know both sides before we commit.
P.S. This is the second company I've worked at where I've seen each project duplicated with the ".Domain" suffix. I've tried researching this but can't really find much info, is it one way of implementing DDD (Domain Driven Design)?
This post has been edited by brendan.hill: 19 November 2012 - 02:12 AM