ArchTest:servicesAndRepositoriesShouldNotDependOnWebLayer should be deleted

[jkoorts]

The arch test tests that Services and Repo's don't have web imports.

That is a problem cause with openapi (a jhipster supported tool) you get a delegate which resides in the web package. You use that delegate in a service. This causes test servicesAndRepositoriesShouldNotDependOnWebLayer to fail.

From an example Delegate:
/**

• A delegate to be called by the {@link ModelApiController}}.
• Implement this interface with a {@link org.springframework.stereotype.Service} annotated class.
  */
  @javax.annotation.Generated(value = "org.openapitools.codegen.languages.SpringCodegen", date = "2019-10-02T16:50:02.286+02:00[Africa/Johannesburg]")

public interface ModelApiDelegate {
}

As you can see the architect of that project thought again that it be right to use this interface in a service .ie "Implement this interface with a {@link org.springframework.stereotype.Service} annotated class."

The jhipster architect thought differently.

How now?

[atomfrede]

I will check what do do about it. The implementation of the delegate might be a service, but from an architectural point of view they belong to the web layer imho, so I guess the layer definition/slicing in the test doesn't take that into account.

[jkoorts]

When you say the service should go into web layer, then looking at the JHipster created the package below. Do you imply that not all @service should go to that package?

/**

• Service layer beans.
  */
  package your.domain.service;

[atomfrede]

Do you have an example? Where did you put your delegate implementation? I think it depends on your desired architecure. I would put the implementation of the delegate under web and annotate it with e.g. @Component. So the arch test makes sure e.g. no web exception (aka zalando problems) are used within your business code. Or more precise no class depends or accesses the class within the web package. If you put your delegate into the service package this violates the constraint that classes in service should not depend on classes in web (the delegate interface). So I don't think this a jhipster issue.

package com.mycompany.myapp.web.rest;

import com.mycompany.myapp.web.api.PetsApiDelegate;
import org.springframework.stereotype.Component;

@Component
public class PetsApiDelegateImpl implements PetsApiDelegate {
}

[fabioportieri]

hello
i had the same problem
i did the refactoring as said by atomfrede, but all the models generated went into *.web.api.model package so i had this problem pretty much everywhere, for now i solved it the easy way by autogenerate all the code inside a .service.api. package

i think the docs in https://www.jhipster.tech/doing-api-first-development/
should be changed since it lead you to write code not compliant for those test

[codecholeric]

@fabioportieri (Just stumbled over this, so I realize this is very old 😉) That sounds strange, because if you did the refactoring suggested, then your OpenAPI implementations would reside within web.rest and thus wouldn't have any problems to call classes in web.api.model? Or did I just misunderstand?

I actually think the complaint is correct, the OpenAPI generated types are parts of the web layer. Generated interfaces should be implemented in the web layer, because the services should be pure business logic and independent of the REST spec / generated classes. In the end these interfaces also define the web DTO types, no? I worked on an application not long ago that did it exactly like that. Implemented the delegates in the web layer and used services from there. IMHO that makes sense for a layered architecture.