Should I use event design when handling no-idempotent invocation? -

i'm working on air booking project.

the image below shows domain model develop far.

we define domain service (airbookservice) encapsulates booking, ticketing , other operations. our suppliers provides remote-procedure-call api handle these requests, implement domain service adding anti-corruption-layer(we have multiple suppliers).

this solution works fine when dealing imdenpotent rpc calls such getting price. however, there risks when dealing non-imdenpotent rpc calls.

for example

public class transactionalreservationhandlingserviceimpl .... {     @transactional     @override     public void modifytraveler(string resid, string tktid, airtravler traveler) {          airreservation res = reservationrepository.findby(resid);          res.modify(tktid, traveler);          airbookservice.modify(res, traveler);          reservationrepository.store(res);     } } 

i place airbookservice.modify() behind res.modify(), rpc call avoided if local domain logic broken. if rpc call succeeds , local transaction fails? have disparity between traveler in our application , in supplier's application.

is worth handling rpc calls , local modification in seperate transactions?

my concern is:

 a) surely introduce complexity if doing so. messaging. b) don' have experience in event handling. c) failure chances low if use rpc call in transaction boundary, caused concurrency problem , contetion of airreservation relatively low in real world. 

below event attempt:

    @transactional     @override     public void modifytraveler(string resid, string tktid, airtravler traveler) {          airreservation res = reservationrepository.findby(resid);          modifytravelerevent event = airbookservice.modify(res, traveler);          handlingeventrepository.store(event);          events.notifytravelermodified(event);// using messaging     }      @transactional     @override     public void modifytraveler(string eventsequence) {          modifytravelerevent event = handlingeventrepository.of(eventsequence);          airreservation res = reservationrepository.findby(resid);          event.handle(res);          reservationrepository.store(res);          handlingeventrepository.store(event );     } 

the advantage local modification seperated rpc calls. introduces: 1.multiple resource management issue(datasource , messaging) 2.i have create lot of ad-hoc event modify traveler, demand ticket , other airbookservice operations.

i'm in dilemma, not satisfied current design quite hesitate new event design.

any idea appreciated, in advance.

in first example mix local modification remote modification. worry if local modification fails after remote modification succeeds cannot roll remote modification anymore. unmixing 2 modifcations way go.

the simplest way swap lines airbookservice.modify call , reservationrepository.store call:

public class transactionalreservationhandlingserviceimpl .... {     @transactional     @override     public void modifytraveler(string resid, string tktid, airtravler traveler) {          // local modification          airreservation res = reservationrepository.findby(resid);          res.modify(tktid, traveler);          reservationrepository.store(res); // <- remember should not store until after commit           // remote modification          airbookservice.modify(res, traveler);     } } 

since local modification transactional commit after successful remote modification. kind of local problems have occurred have occurred. of course, there still minuscule chance committing transaction fails. therefore transactional, have able roll remote modification. since, take it, not able so, true transactionality impossible. above construct therefore safest possible way in terms of consistency local , remote modifications @ same time, since chance commit of local modification fails negligible. this, because if introduce messaging there still similar slight chance message not committed after remote modification.

the above construct have 1 big issue: hamper performance pretty (you don't want transactions lingering long). messaging therefore reasonable solution problem. has other advantages, persistence, auditing , replaying of messages. messaging attempt therefore quite legit in respect. code break single responsibility rule since messaging mixed modification within same method calls.

if concerned boilerplate around messaging should check out akka.io. spring jms , activemq pretty powerful combination if not looking entire paradigm shift, decent messaging solution. using 1 of these 2 technologies i've suggested can create powerful framework local calls paired remote calls allows avoid lot of boilerplate.

i hope helps. luck!