One of the most common misconceptions I hear about Oqtane is that you must follow the specific conventions used in the core framework and default templates in order to develop custom solutions on the platform. This is in fact NOT correct, as Oqtane actually offers tremendous flexibility to enable developers to use their preferred methodologies and components.
The Oqtane framework was architected so that it can support a wide variety of environments. In particular it is multi-platform and supports multiple Blazor hosting models, multiple database engines, and multiple multi-tenancy models. In order to support all of these environments in a single application using a single code base, it needs to leverage a variety of abstraction layers. This enables the framework to adapt at run-time to the specific characteristics of each environment.
That being said, most developers do not have the same requirements as Oqtane. Generally they will only need to support a single platform, using a specific Blazor hosting model, a specific database engine, and a specific approach to multi-tenancy. These are much simpler requirements which means that the development of custom solutions can often take a much simpler approach.
To put this into perspective, let's consider an example where an organization has chosen Microsoft as their technology platform. They are using Windows and plan to deploy their application on Windows Azure. The application will be internal to their organization so they have decided to use Blazor Server as the hosting model. They use SQL Server as their database engine and prefer to use Dapper for data access. They have a depth of database experience and prefer the flexibility of using SQL scripts to provision their database schema (as opposed to migrations).
The scenario above includes many specific technology choices - choices which differ from the default implementation examples and templates in the Oqtane framework. However, these choices are still 100% supported by the Oqtane framework. To demonstrate this fact, you can review the code for this sample module which was created using the default module template but was modified to use Dapper and SQL scripts for its database aspects. You can see that the modifications are straightforward and the module is fully functional within the Oqtane environment.
Note that there are many other customizations which would be possible as well - many of which would reduce the overall code footprint considerably. For example, removal of interface classes in favor of just using concrete classes. And since the organization only needs to support Blazor Server there is no need for a client/server approach, so the Client, Server, and Shared projects could be combined into a single Server project. Obviously the end result would no longer resemble the default Oqtane module template, however the module would still support core Oqtane concepts such as multi-tenancy, security, localization, etc...
We have all heard the saying "don't judge a book by its cover"... so I guess the software development equivalent would be "don't judge an open source solution by its sample code" ;)