Topic on Talk:Wikimedia Engineering Architecture Principles

A separation into three "layers" seems to be industry standard: storage, process, and presentation (note that this is conceptually analogous to, but different from, the MVC pattern used in user interfaces).

This separation of concerns would help to allow the implementation of different interactions/flows and different representations for different users, use cases, and devices. It's not the only way to achieve this, but it seems to be an obvious win. Should it thus be part of the architecture principles?

Suggested wording: The software stack SHOULD be separated into three layers: storage/persistence, processing/application, and presentation/interaction.

I don't think this is useful without further clarification. For example, MediaWiki has a database abstraction layer; is that the same as the storage layer, or is a storage layer expected to encompass all knowledge of DB structure? What about caching and cookies (technically all forms of persistence but often awkward to separate from processing logic)? What is "interaction", does that include processing request data? How do these apply to an application where a significant part of the logic is frontend code and "interaction" has very different meaning from the request/response based web applications?

In my mind, the storage layer should abstract all knowledge of what technology is used for storage, and what schemas we use in these technologies. Ideally, application logic is completely isolated from that. Cookies should be handled by the Request/Response layer ("presentation" layer is misleading, since it also deals with request parameters, input validation, and user sessions). Caching can happen in all layers. The storage infrastructure behind caching and session should be encapsulated in the storage layer.

So yea... this seems too specific for "architecture principles". These are more "architecture techniques" or something...

Maybe you could articulate the reasons for having separate storage etc. layers, and try to turn those reasons into principles. Is it to minimize the amount of code that depends on technology choices (such as storage engine)? To minimize the amount of code that deals with data in an uncertain format (user input, old data from storage)? To separate code that is expected to change often from that which isn't? To enable certain types of site customizations?

yes ;)