Avoid tight communication between classes of service

Question

Let's say I have 2 classes of service:

UserService ProductService 

Is it wrong if I insert a UserService in my ProductService class?

 public class ProductserviceImpl implements ProductService { @Autowired UserService userService; @Override public void someThing() { .. userService.otherThing(..); .. } } 

I know as an alternative , I could create another class that introduces both UserService and ProductService, but coming up with a name for this class is very difficult :) Is there a name for these types of classes in the SOA world?

Answer 1

There is no problem for me to enter the service in another. This is the point with services and SOA, as you said.

Services can help each other to give you the final result. In addition, as JB Nizet said, if there are no cyclic dependencies, there are no problems.

Answer 2

1) Is it wrong if I insert a UserService in my ProductService class?

There is nothing wrong with the following reservations:

• Keep in mind that you can potentially move in the direction of one class doing too much (here ProductService)
• Be careful that you do not introduce circular dependencies (you should not have a UserService also dependent on ProductService)
• Limit hard communication by connecting your dependency to an interface, not to a specific class (here you use AutService UserService instead of UserServiceImpl, which is good).

2) Is there a name for this type of class (which introduces both UserService and ProductService)?

Yes, as already mentioned, you could call this class a Mediator, since the "Mediator" seems to describe it.

You can have both low-level services and high-level services, and low-level (ProductService, UserService) are embedded in high-level (say, PurchaseOrderService or PurchaseOrderMediator). Alternatively, for this particular case, you might think that the product service is the only high-level service that depends on the UserService. At this point, its more about which design is more cohesive in the context of your business logic and your application.

Answer 3

What you are describing is called an intermediary pattern .

What is SOA?

Answer 4

Including one service in another using spring, as you mentioned, will be paired, 2 services only to the extent that the interface is used.

If you need more decoupling, consider using a message to transfer between two services.

A message can be strictly printed as a value / xml object using a circuit or weakly typed as a HashMap

While poorly typed messages can increase decoupling, this means that you and your client will lose compilation and debugging time and will be cumbersome at runtime

Answer 5

What you are describing is object-oriented integration and most likely not SOA. This suggests that you can get (and avoid) cyclical dependencies.

If you know the services of other Java-level interfaces in Java, you also run the risk of introducing a hard link. For example, what type of return is used in the user service? is this another interface that belongs to the user service? Do you pass it in the product service code?