21

The general trend these days is to limit the number of projects in a visual studio solution:

The two project solution Project antipattern Multiple projects considered harmful Evolutionary project structure

The helix documentation and Habitat are implemented with many many projects in the solution. This to me seems like a serious code smell. If I were to implement a Helix solution with a limited number of projects, how minimal could I go?

I think I would start with 4: Project, Foundation, Features and Tests.

What would I lose by not having 65 different projects? Or what do I gain by having them? If it's only organizational, then easy peasy. What dependency control is achieved with many projects? Maybe I'm missing something, but at this point, the pain seems to far outweigh the benefits.

Improve this question
4
  • 1
    There might be a valuable and worthwhile question in here, struggling to get out. However "Why does it seem like no else is addressing this what I would consider to be anti-pattern?" is not a question anyone can answer. Can you please clean up the question a bit, and state what it actually is you seek an answer to?
    – Mark Cassidy ♦
    Commented Jan 1, 2017 at 14:12
  • 4
    This is more of a topic for discussion and less of a question with a clear answer. I totally agree with your perspective and it's a question we've faced internally as well. The use of Gulp and other task tools can help with having potentially dozens and dozens of projects. What Helix and Habit don't showcase, is how you might end up with even more projects if you decided to split a feature into different layers (Data, Core, Web, etc). So each feature would have potential a half dozen projects. The real question here is, does having more projects hurt developer performance
    – Dylan Young
    Commented Jan 1, 2017 at 17:03
  • This is something you should raise as a Discussion item in community.sitecore.net - I suspect most of the arguments you will get will be with your initial assumption. There are many advantages to organising code into projects that are not accessible if all your code is in one project. Key among these are re-usability between projects, risks during deployments and SOLID principals.
    – Richard Hauer
    Commented Jan 3, 2017 at 3:21
  • I can't stand this weird structure as well. It's not beneficial at all for the medium-scale solution, there is not reason to have everything stuctured in folders in one project. Multiple projects only complicate load time, VS performance, deployments and so on....
    – Jack Spektor
    Commented Apr 20, 2018 at 1:20

1 Answer 1

Reset to default
21

From a architectural point of view there is no reason not to have everything in a single project. This will certainly make load and build times quicker - if that is the aim.

The reason for splitting up modules into projects is to clearly define boundaries for modules so that dependencies are as visible as possible, which increases productivity, reduces cost of maintenance and simplifies extensibility.

In other words: if you are comfortable with having your development team managing cross-module dependencies within a single Visual Studio project there is no reason to split up into several projects. There are even tools which can help you control the module dependencies in solutions with fewer projects.

Projects Define Boundaries

However, you should keep in mind that your project lives beyond the initial development phase - and most often beyond your and the initial development team's involvement. In a typical application lifecycle, the technical debt, dependency creep and other productivity decreasing factors happens in the delivery and maintenance phases. The ambitions of clean code and architecture often crumbles with deadlines, team handovers and quick patches. Solution structure is there to define the architecture - both in the short and long run. Defining boundaries as clearly as possible is very helpful in making sure your architecture stays clean.

I recommend watching Anders Laubs talk from the Helix workshop at Symposium 2016 which covers boundaries and why we need them: https://youtu.be/C1OvZOVYous?t=14m38s.

Improve this answer
4
  • 1
    Based on my experience on a recent project, this kind of extreme solution architecture actually increases technical debt because basic development becomes so difficult that it encourages developers to take shortcuts. Yes, you need some organization to your solution, yes enforcing dependency rules is important but if you make development wildly difficult you slow down development and actually end up with more technical debt, not less.
    – Ethan Schofer
    Commented Jan 9, 2017 at 0:00
  • 2
    I think your point is valid. But let's play with the though of doing the absolute minimum: All templates are under /templates. Fields are straight on the page templates. We have a single Visual Studio project to handle the entire solution. View renderings over controllers. Simplicity and straightforwardness over anything. You will probably agree that this "simple" (or lack of) architecture is no good either - especially when the solution grows. When do we start adding conventions to separate concerns - and which concerns are more important than others? Will we even have time to refactor later?
    – Eldblom
    Commented Jan 19, 2017 at 10:11
  • 1
    Yes, there does need to be some structure. After reviewing Uncle Bob, I think one issue is I disagree with the implementation of the package principle. He states that you should package things that should be deployed together. I would give up my ability to deploy just a single component in order to have a project that didnt hamper development so much.
    – Ethan Schofer
    Commented Jan 19, 2017 at 14:39
  • I think there is a happy medium when it comes to Helix. Should every single thing you build (if it's not the same as something else) have it's own project? No I don't think so. But at the same time should everything for foundation or feature consist of only one project per layer, no that just leads to more problems as well. I think you should really focus on separating similar types of functionality into separate projects. This leads to only 20 to 30 projects. Ultimately it's up to your organization, to come up with a standard and to stick with that standard.
    – Dylan Young
    Commented Mar 26, 2018 at 17:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.