CODEWITHSUNDEEP
javaspringeventsarchitecturejms
rayman
rayman

Reputation: 21596

Architecture event driven advice

Lately I have upgraded my application work in an event driven architecture using Spring3.1

I was wonder what do you think:

  1. having a DAO instance in each class which has the need of inserting/updating/etc record in the DB.(regular way)

  2. shall I send messages to DAO(via jms/channels/whatever) and the message's content will be the instructions of what I should do (inserting/updating/etc record in the DB)

how way number 2 is good in a loose coupling manners?

maybe it's overkill ?

this or any other suggestions or advice are welcome.

thanks. ray.

Upvotes: 1

Views: 724

Answers (1)

Sanjay T. Sharma
Sanjay T. Sharma

Reputation: 23208

Loose coupling doesn't mean "adding" more concrete layers to your application (a message queue etc.). If the "service" implementation classes interact with the DAO layer via interfaces (Spring DAO bean injection is a perfect use case which comes to mind), you are pretty much operating at an abstract level.

If you then swap out the concrete DAO classes injection with a messaging client which posts message to another service, your code will continue to function as it was previously without significant changes. Of course, there is always a disconnect between the blocking/non-blocking approach but nothing which a good abstraction can't solve. My suggestion would be to look into framework/libraries like Guice for creating the initial draft/refactor of your application as opposed to adding new layers. If then, at some point you feel that non-blocking DB calls are the way to go, you can implement them easily. Putting that logic upfront would just increase the technical debt.

Upvotes: 3

Related Questions