How to reorganize microservices when they all share data and concepts?

At our company we use the microservices approach because we like to keep services small, understandable and maintainable. Besides that, we use a load balancer which enables us to duplicate heavy used services.

We understand that microservices should be loosely coupled if coupling is needed at all. Also, the coupling should not happen on the database, but preferably by API's (REST).

Well, we use the microservice idea. We don't apply everthing that is recommended. In our case we use loosely coupled Tomcat War's that communicate via REST and JMS messaging. All webapps use the same database server, but they all have their own scheme (so no integration).

We have two issues with this approach:

1. 75% of the services generate report data. There is a report service that is responsible for persistence and serving of that data. So all services that generate report data send their findings to the report-service. In fact, each service has it's own responsibility, but still we need all this communication. This seems to conflict with the microservices idea. It is like a horizontal layer that binds all vertical microservices together.
2. Due to the 'horizontal' coupling above, we also share interface objects. Report data is structured in a certain way. And every service needs to follow that structure. We have a strong feeling that shared libraries of domain / interface objects is against some principles. But as you will understand, duplicating all interface objects seems dumb and still a lot of work when interfaces change.

An alternative to the current architecture is that every service persists it's own report data. Then you only need the communication when the report is rendered. In that case we don't have the regular communication between services and the report-service. Disadvantages are now that every service needs it's database layer (there was no), and that you still need to share report structures among all services.

The high-level question is: is there a pattern for dividing services when behaviour can be separated horizontally and vertically?

The same issue may occur in a sales application where the 'product' plays a central role through the entire set of services.

Should we redesign the architecture? Is there a pattern we can use? or is this an already known anti-pattern?