search

devonfw / devon4j

devonfw Java stack - create enterprise-grade business apps in Java safe and fast
Apache License 2.0
83 stars 87 forks source link

JMS senders should not be part of data access layer, but logical layer #354

Closed maihacke closed 3 years ago

maihacke commented 3 years ago

Our JMS guides tells that JMS senders should be part of the data access layer. This is inconsistent to other parts of devon architecture (e.g. http-client, kafka-sender). Adapters to other services should be part of the logic layer.

hohwille commented 3 years ago

I am not entirely sure if we have the same mindset here or what is the gap: With your argument you could also kill the service layer and move the REST services into the logic layer (and also put the business logic directly in the REST service impl instead of creating use-cases).

The intention of the architecture is to do SoC. JMS is a database technonolgy and IMHO belongs in the dataaccess layer. There we transfer the technonogy (JMS, potential marshalling and or mapping to our Java objects - BOs) and then usually delegate to a use-case that will process the resulting data that has been received via JMS.

Do you want to avoid boilerplate code by putting both in a single class? Or is your intention different (e.g. because of the constraints I might be missing)?

hohwille commented 3 years ago

OK, simply clarified in a call with @maihacke Here we are talking about the outgoing sending of messages and using any kind of component or shim that encapsulates the technology (here JMS e.g. via spring JMS template or whatever, in other cases its the same with sending an RPC call via REST where we provide devon4j service client, yet another case is sending Kafka message, etc.). So we are not talking about the layering of the "component or shim" that is sending the message but the invocation of that. This belongs into the use-case and that is all compliant to our architecture: https://raw.githubusercontent.com/devonfw/devon4j/master/documentation/images/T-Architecture.png

The change intendet by the PR simply wants to avoid that someone might be mislead and think he needs to create a kind of DAO or Repository in the data-access layer that does noting but wrapping the existing "components or shims" we already have from frameworks like spring, quarkus, etc.