I've been thinking a lot about the organization of Foundation.Abstractions modules (organizing base-types for IoC that Feature - and potentially Foundation - modules use), and I am a bit torn on whether Foundation.Abstractions should really be a single module, a grouping of separate, more granular modules, or else if it should just be core abstractions with other abstractions living in their own, separate Foundation modules.
Putting IIndexableFoo
in the same module as IBazWeatherServiceManager
(made up interfaces for illustration purposes, only) doesn't feel right to me, since I should be able to remove one the "Indexing" or the "Weather" feature without affecting anything else. I feel like what I should be doing is instead adding sub-modules to Foundation.Abstractions (i.e. using Foundation.Abstractions as a module group and adding a new module to that group). In this case, I might have something like Foundation.Abstractions.Indexing and Foundation.Abstractions.Weather.
In contrast, I know that the Foundation.Abstractions module shouldn't really be aware of what purpose it will server or by which features it will be used. As such, even though it is perfectly acceptable in Helix to group multiple modules together as a single module, I feel like breaking Foundation.Abstractions up the way I described in the example might actually violate the concept that Helix was aiming for. To elaborate, what I mean is that if I were to split up my Foundation.Abstractions module by purpose, I would inherently be making said Foundation layer module aware of the purpose.
The other option that I have is to create separate Foundation layer modules for the different abstractions, and reserve Foundation.Abstractions for core abstractions. In the case of the example I described above, this would likely entail having modules like the following: Foundation.Indexing.Abstractions, Foundation.Weather.Abstractions, and Foundation.Abstractions (or Foundation.Core.Abstractions if Foundation.Core exists and is a module group).
Can anyone help me straighten out the guidelines on when to group abstractions and which would be the better practice when following Helix?
UPDATE:
In the example, above, "Weather" was actually a poor choice. The "Indexing" example illustrates the correct point, as it is for a feature that is/modifies part of the platform. I don't want to change the post yet, in case people are currently writing answers, but instead of "Weather" you can think of something like "IEventHandler" or something else that is/modifies part of the platform.
Indexing
foundation project in another sitecore solution. In case indexing is mixed with whatever IEventHandler (etc) abstractions, you are potentially bringing redundant stuff along, which is super unnecessary and confusing. tldr: dont group unrelated abstractions