Topic on Talk:Architecture:MediaWiki/Technical layers

The proposal as of the time I'm writing this comment has 12 layers. That feels like too many. I'm concerned that absorbing and applying the knowledge of what layer a piece of code should exist in will be intimidating to newer developers. I'm also concerned that it will be a source of less-than-productive debate for experienced/opinionated developers.

Intuitively, 5-7 layers feels like the correct amount.

I am intentionally not suggesting which layers should be combined or what the new set of layers should be, because I don't think it is relevant. Yes, clearly we would have to determine that if we adjust the proposal. But my focus in this comment is strictly on my concern that the average human would have significantly more difficulty categorizing things into 12 buckets than 5-7, based on https://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two .

And yes, I realize the article I just linked allows up to 9 things. But given the overall complexity of MediaWiki, a person already has a lot crammed into their brain while doing any significant development on it. So I feel we should err on the lower side of that range.

Right, I fear this is a result of me trying to be overly neat... Some layers could be combined, others are not "proper" layers. It would probably best to focus on the ones that are most relevant for most code. Perhaps something like this:

• (surface layer)
• user interface layer
• API layer
• behavior layer
• processing layer
• storage layer
• entity layer
• (foundation layer)

That's six real layers, plus two for "stuff above" and "stuff below". How does that sound?

If this is still too much, processing could be folded into storage. Structurally, that wouldn't be too terrible, though I'd like a better name, then.

We could also combine API and UI into an integration layer, but we'd lose a restriction I find important: the API shouldn't know about UI concepts and flows, it shouldn't care about i18n. Unless we are talking about a backend-for-frontend API, which would probably live in the UI layer...

This looks much better to me at a glance. There's probably room for discussion about whether or not this is exactly the right set of layers. But this seems like a good starting point for that discussion.