英文:
Spring/Java project hierarchy: Where to put none model POJO classes?
问题
FooResponse应该位于dto包中，你可以选择使用dto.foo.FooResponse.java或者只使用dto.FooResponse.java。
英文:
I have a @Service class FooService that queries some external API. In return, it gets some FooResponse. This FooResponse is being used to create the model object but it's not a model by itself.
The project has a typical Spring project hierarchy (i.e. service, model, controller, config, utils)
Where should FooResponse reside at? Is it a dto?
Would you go with dto.foo.FooResponse.java? Or maybe just dto.FooResponse.java?
答案1
得分: 2
If you can define your architecture using hexagonal architecture, then you should define the domain model called Foo in the domain/application layer, and FooService should return the Foo domain model. FooResponse can be encapsulated in FooServiceImpl.
Package Structure:
com..application.model.Foo
com..application.service.FooService
com..infrastructure.service.impl.FooServiceIml
Interface FooService:
Foo getFoo(T someParameter)
Class FooServiceImpl:
com..infrastructure.service.impl
public class FooserviceImpl {
public Foo getFoo(T someParameter) {
// call external service
// getFooResponse
// Map FooResponse to Foo and return Foo
}
In hexagonal architecture, the application/domain layer does not depend on the outer layer (presentation, persistence, infrastructure). The benefit of this architecture is that you can change infrastructure code without affecting business logic (for example, FooServiceImpl can be changed to use gRPC instead of REST without any change in application logic).
英文:
If you can define your architecture using hexagonal architecture then you should define domain model called Foo in domain/application layer and FooService should return Foo domain model and FooResponse can be encapsulated in FooServiceImpl
Package Structure
com..application.model.Foo
com..application.service.FooService
com..infrastructure.service.impl.FooServiceIml
interface FooService
Foo getFoo(T someParameter)
Class FooServiceImpl
com..infrastructure.service.impl
public class FooserviceImpl {
public Foo getFoo(T someParameter) {
// call external service
// getFooResponse
// Map FooResponse to Foo and return Foo
}
In hexagonal architecture application/domain layer does not depend on outer layer (presentation, persistence, infrastructure). The benefit of this architecture is that you can change infrastructure code without affecting business logic(for example FooServiceImpl can be changed to use gRpc instead of REST without any change in application logic)
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论