devonfw / java Goto Github PK

In regards to serverless architecture and microservices that only have a limited set of functionality (up to only CRUD services)

How do you structure those services best. Usually the currently defined layered or hexagonal architectures are too much of an overhead.

There're a lot of things in regards of performance to take into consideration when using JPA.
Those should be documented as rules in the JPA performance article.

A list of possible rules that @hohwille suggested in #27 :

• Only load the data you need
• Only load the data when you need it (e.g. in a search result screen you do not need to have all the details loaded from DB tier to app tier into frontend but only minimal sets of the records to display, once the user selects a search result for expansion or to open details screen then load the details for that record).
• Declare all your JPA relations as lazy but avoid triggering of lazy loading at all - it is a stupid feature of JPA. Either you do not need to load things at all in your TX or you need them. If you do, then lazy loading only leads to N+1 problems and waste so simply load eagerly then (not via Annotations but via the query - e.g. using FETCH JOIN).
• Check the execution plans of all your queries, in case of Oracle check AWRs and statistics frequently on production
• Create indices - a rule of thumb is create an index for every foreign key column and consider indexes for all searched columns but not blindly but after checking execution plans
• General rule: Ensure to have an expert for your DB technology in your project in case you are doing something serious (millions of records, anything below is peanuts and may work without deeper knowledge)
• Avoid conversions (Cast, TO_DATE, TO_NUMBER, etc.) in your SQLs
• Ensure that data-types in variable bindings fit to your DDL. Oracle does not convert the given variable value to the DDL type to convert to but instead converts every column value to the data-type you provided what can lead to catastrophic performance and DB CPU drain, etc.
  Never use Criteria API - it sucks and leads to disaster (I have rescued a big-data project and mean it)
• Do explicit joins (selecting from multiple tables and then "joining" in WHERE clause makes hibernate to do cross-join what makes Oracle build the Cartesian product before evaluating the WHERE clause. If both tables to "join" are really big this will lead to an ultimate disaster (DB IO death)
• Avoid WHERE ID IN (...) expressions and be aware of limitations (1000 values for Oracle). Instead think if you can use a sub-query to avoid having the list of IDs in the first place.
  so much more to tell - we should collect input from DB community, projects, etc. to get all the valuable knowledge collected.

Explain how a modular monolith can be structure with java and maven.

The current idea is to use maven modules to:

• structure the overall application into business components. Each component becomes a separate maven module
• structure each business component
  • The core as an own module
  • Each adapter an own module

To get the dependencies aligned use the dependency management of maven and create an application wide parent.pom to controll versions and used libraries

The article should be splitted into two parts:

1. Explain the modularization of one business component
2. Explain the modularization into business components.

In general give an overview of the benefits and concerns of this approach compared with a package structure.