I’m currently working on refactoring one application. It is an application for a leasing company. The application comminicates with external systems via web services. Some changes in the state or some events require to call external system. We have two types of calls:
- synchronous – for example, when I add an object to a leasing application the number of the object is taken from the external system (I wait for the response).
- asynchronous – when I change the data on the application the changes are also send to external system (the message is stored in our custom queue, and I don’t need to have the response from the external system)
The design of the application was not prepared for the growing number of the external system (in every release we add at least one system). We have one layer (Logic) which handles all the bussiness logic and also communicating with external systems (which consists of building request, validating request, sending message, validating response, handling response).
I would like to separate the communication part from the bussinness logic part. What design patterns are good in this situation? I have read the Design patterns @ sourcemaking.com, and also Catalog of Patterns of Enterprise Application Architecture @ Martin Fowler’s but either there is nothing I can use or I don’t see the way I can use it (most likely it is the later 🙂 ).
Hexagonal architecture all the way! 🙂 – http://alistair.cockburn.us/Hexagonal+architecture
It’s a great way to separate your business logic from the way your application receives and sends events to the external world.
The Hexagonal Architectural pattern might be a bit too high level, so I usually suggest to read the Dependency Inversion Principle before, to understand how the model should expose interfaces that are later implemented by the adapters.