Since you asked so nicely:
I’ve decided to create a documentation of Architecture Guidelines, targeting the idea of a minimalistic Java EE Tech-Stack. These guidelines are now my simulation of the enterprise architecture I’m missing so badly. Whenever I get new insights into what business or infrastructural restrictions we have, I can update these guidelines and start working on my projects from there.
It’s like my very own anti-corruption layer, but on the level of company communication.
It’s grown into a 14 page monstrum, and still isn’t even done yet. I wish I could show you, but it’s in German and probably not conform with compliance, even if I remove all indications of what decisions point to which end of our organization.
Within this document, I’ve divided these sections:
-
Database / Data-Sources
-
Data Access and Sanitation
-
Business Logic (WebAPI)
-
Presentation Logic (WebSite/GUI)
Because I’ve decided to go as modular as possible, I outlined each of these parts as a Subsystem.
It took weeks of work, but in the end I got a wholesome concept on a very high abstraction level. It describes dependencies, concerns, risks and chances with each layer. It is also naming the most important standards and patterns for this or that layer, supposing a Java EE implementation.
This gave me a foundation to base my Project decisions on, and a guideline to recognize and cut tasks into comprehensive chunks, either for my own planning or for my trainee developers. I don’t have to visualize all the risks and dependencies in a big monolith anymore, which is a huge advantage.
Although it targets a Java EE implementation, it’s also too abstract to be considered “strongly typed”. As you said, it’s easy enough to upgrade from Java EE to any framework. It’s that thought in particular I implemented into my architecture: Keep things simple and “basic”, as to allow for future sophistication.
So… who’s won?
I feel I should be more clear about how this connects to the topic.
In the beginning, there was a choice to be made. Java EE vs Spring vs Struts vs You-Name-It. Which way to go?
Because I’m in an abstract situation, with future projects generally ahead of me, I need a more abstract, general approach to the question of tech.
My above mentioned guidelines provide this:
Whenever I face a new project, I begin plain and simple, and with Java EE. My customers, the stakeholders and I become more familiar with the project, and as we do, we better understand what tech we need. Since most frameworks build on Java EE, the extra effort to implement a framework later in the development process is acceptable, while the decision can be backed with real experience.