Strimzi consists of 3 different layers (at least in the case of CO - from the bottom layer to the top):

• The API layer which defines the Kubernetes API (essentially the api module)
• The Model layer consisting of classes in io.strimzi.operator.cluster.model which covers mostly the translation of the API to Kubernetes and Kafka (configs, certs, etc.) resources
• The Operator layer which is responsible for executing the actions (managing resources, talking with Kafka etc.). These are the io.strimzi.operator.cluster.operator and io.strimzi.operator.common.operator packages.

We should enforce separation between these layers and make sure that the classes from a lower layer do not use directly the classes in the upper layer. For example:

• The API layer classes should not use any classes from the Model or Operator layers
• The Model layer classes should not use any classes from the Operator layer

The first point is easily achieved since the API layer has its own module api which does not depend on the other modules. But the Model and Operator classes share the same module. So there is currently nothing preventing the Model classes from using the Operator classes. In fact, there are several such situations. So we should:

• Fix the existing situations where this separation is broken
  • In many cases, this seems to be because classes that should be in Model are in Operators
  • In some cases, refactoring will be needed to fix the separation
• To ensure the separation, we should use the Checkstyle plugin and its import-control feature to prevent Model classes from importing any Operator classes. This is already used for example in Apache Kafka itself.

(If needed, we can split this into additional JIRAs to minimize the scope of the individual PRs.)