[Question] Reasoning about Foundation.Acount module

[sshushliapin]

Few days ago I asked if it makes sense to stop propagating 50+ project solution which I found over-complicated and over-costed. This started a discussion here which I'd like to supplement with a real world example from Habitat.

So, could you please explain what is the reason of the Sitecore.Foundation.Accounts module to exist? If you take a look, it consists of 5 (!) classes. In fact, there is only 2 things in there:

1. Log in pipeline definition (here and here)
2. Extended facets (here and here)

The only consumer of this module is the Feature.Accounts unlike, for instance, Foundation.Dictionary which is used in 5+ projects and IS a true foundation module. Including the existing Foundation.Accounts into Feature.Accounts will not harm but only simplify the solution.

Thought? //@asmagin, @anderslaub, @cassidydotdk

p.s. I predict answers like we're enabling a possibility extend the pipeline in some other feature later. I prefer to stick to YAGNI principle.

[nickwesselman]

I haven't spent the time to investigate, but if what you say is true re: dependencies on this module, then there should not be Foundation.Accounts module. Helix is not intended to advocate for premature optimization and this would then be added to the list of reasons why Habitat is being replaced. 100% agree on YAGNI principle and I'm in support of updating Helix in places where it seems to advocate for premature optimization, e.g. Sitecore/Helix.Docs#30.

[cassidydotdk]

Helix is not intended to advocate for premature optimization and this would then be added to the list of reasons why Habitat is being replaced. 100% agree on YAGNI principle and I'm in support of updating Helix in places where it seems to advocate for premature optimization, e.g. Sitecore/Helix.Docs#30.

While I'm sure you believe that; Helix is 100% a case of optimising prematurely and often needlessly. It advocates splitting up your application according to some in-house principles used at a Danish Sitecore Partner (that had the time and money to train staff using these principles) and up front taking the hit for abstractions (Foundations, Feature) that may or not be relevant at some point in the future. Not all solutions ever mature to the scale where this sort of abstraction is required.

Everywhere Helix proposes a certain style of organisation (e.g. "put your so and so into the Foundation folders"), this is the case. It goes too far.

[nickwesselman]

You have to organize your solution somehow, and having common semantics for organizing a solution benefits all of us. I am 100% on board with simpler/consolidated projects structures in Visual Studio, as you are aware. Helix is meant to be pragmatic as well. Is it a small site that you know will be short lived? Then by all means build everything in the Project layer and be done with it. Whether this flexibility has been advertised well enough is another question and is something we are improving upon.

Any question of YAGNI needs to reflect probably vs cost however. What's the probably that a solution will grow over the long term and thus require / benefit from modular architecture? Or that another development team will take over its maintenance? And what's the cost of implementing that modular architecture from the start vs trying to refactor to it later (which we know will never happen)?

Helix was in part born out of the failure rate of large Sitecore projects, so the base recommendations are going to be oriented to those. But again 100% agree that we need more detail on scaling it.

I'm going to close this issue on the Habitat repo as it related to a specific Habitat module. There are existing open issues/discussions on the Helix.Docs repo related to this: https://github.com/Sitecore/Helix.Docs/issues