Tag Info

New answers tagged

2

The most architecturally sound approach I know of is to put that single source of truth behind a microservice. It is perfectly okay for multiple parts of the system to update that data, as long as they do it through something like a microservice that can ensure it's always done correctly and predictably. So for instance, Customer data is probably already in ...


1

Ok. Problem 1: getting DTO's from entities: Since your entities can expose thier data publicly you can access their properties and instanciate a DTO object or simply serialise the entity directly Problem 2 : Entities from DTO's: A constructor method which takes a list of the properties to be set can be called using the properties of the DTO Problem 3 : ...


0

I think this: Should you write your back-end as an API? is a verry good summary of your thoughts. Thanks to gbjbaanb for this answer!! The benefits of writing the backend as an API from beginning will save much time in later development process. Another point are the security reasons. Two systems are much better than one. The next thing is, that one team ...


1

ESB: Reliable delivery of a message is the responsibility of the transport. Successful delivery can mean very different things depending on context, see Quality of Service (QoS) 1, 2, 3. An ESB in a Service Oriented Architecture is normally responsible for routing and transformation as well as value add options such as monitoring, auditing etc. RESTful ...


1

It depends. The point of a message passing architecture is that the sender doesn't care who receives the message, and while this means a fire-and-forget approach works very well, it isn't suitable for some situations where either guaranteed delivery is required, or a acknowledgement is received. Fortunately the latter approach is very easy - the receiver ...



Top 50 recent answers are included