Spring/Java项目层次结构:在哪里放置非模型POJO类?

huangapple go评论19阅读模式
英文:

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)

huangapple
  • 本文由 发表于 2020年7月23日 00:55:17
  • 转载请务必保留本文链接:https://go.coder-hub.com/63039395.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定