New answers tagged

0

Yes, you should have a microservice to call/hide the third party API. That service's job is to know how to call the third party API. Not only because it's messy, but to avoid carrying the idiosyncrasies and implementation details of the third party service into your design. Also, this gives you a chance at abstraction or generalization. You can then switch ...


5

I encounter this type of thing all the time, there are some unbelievable commercial SOAP/XML APIs out there. What I normally do is basically two things: Define a facade for the functionality my service actually needs. This is a simplified interface that exposes the things my service cares about in a consumable way. Create an adapter between the external ...


4

The issue that you have is that you merge the concept of user and the concept of role. So if the same person is head of procurement in several tasks, that person would have several unrelated objects. A first step forward would be to use sound separation of concerns, for example as follows: As you see, I renamed your initial "User" into "Contributor" to ...


0

No The argument was made however that this is a flawed approach and that my DAOs should not be structurally tied to my domain model. I am trying to understand if this is so and why. Because you cannot inherently rely on your domain and entity models to match. In a comment on a (now deleted) answer you said: Appreciate the response, but find my self ...


Top 50 recent answers are included