Следует ли смешивать технологии в сборках?

У меня есть проект среднего размера, который реализует около 20 различных концепций. В начале , Я решил организовать свои сборки на основе концептуальных уровней, например так:

MyProject.Domain.dll (References System.Data.Linq, etc.)
  \ConceptA\
  \ConceptB\
  \ConceptC\
  \...\

MyProject.Presentation.dll
  \ConceptA\
  \ConceptB\
  \ConceptC\
  \...\

MyProject.WinForms.dll (References System.Windows.Forms, etc.)
  \ConceptA\
  \ConceptB\
  \ConceptC\
  \...\

MyProject.App.exe (References all the above)

Я недавно прочитал в книге DDD, что мне следует сгруппировать свои сборки на основе концепции предметной области, которую она представляет, а не технологического уровня, например:

MyProject.ConceptA.dll (References System.Data.Linq, System.Windows.Forms, etc.)
  \Domain\
  \Presentation\
  \WinForms\

MyProject.ConceptB.dll
  \Domain\
  \Presentation\
  \WinForms\

MyProject.ConceptC.dll
  \Domain\
  \Presentation\
  \WinForms\

MyProject.App.exe (References all the above)

У меня недостаточно опыта, чтобы судить об этих двух подходах в долгосрочной перспективе. Я хочу найти наилучший баланс между сложностью и гибкостью. У меня есть несколько проблем, которые вызывают у меня двойственное чувство:

• Группировка по концепциям делает мой код легче найти, так как он находится в одном месте.
• Группировка по технологиям гарантирует, что я не буду вызывать MessageBox.Show из моего уровня домена.
• Я в конечном итоге отключу доступ к данным и технологии представления.
• В конце концов, все сборки будут ссылаться на в любом случае основное приложение.
• Куда пойдут тесты, сгруппированные по концепциям? Разве мне не придется помещать их в отдельные сборки, чтобы они не поставлялись вместе с программой?

По вашему опыту, какой подход лучше всего?