Reputation: 11
I am developing a Spring Boot application using hexagonal architecture. The application uses two Spring State Machines: one for a requesting process and another for a receiving process. My primary challenge is effectively integrating these state machines within the hexagonal architecture, especially considering the following requirements:
Questions:
1. Business Logic Implementation in Hexagonal Architecture:
In a hexagonal architecture, where is the best place to implement the logic for state transitions, especially considering the need for sending/waiting for messages and making REST calls within certain states?
2. State Machine and Service Layer Interaction:
How should I structure the interaction between the service layer and state machines in this context? I am looking for best practices that fit within the hexagonal architecture paradigm and ensure maintainability. Configurations for State-Dependent REST Calls:
Could you provide examples or best practices for configuring state machines in Spring Boot where states involve making REST calls?
3. Handling Message Responses:
How can I effectively manage the scenarios where the state machine sends a message and needs to wait for a response before moving to the next state?
4. For state transitions what is better to use Actions, Listeners, or Services?
Any guidance, examples, or best practices would be immensely helpful. Thank you for your time and assistance!
What I've Tried and What I'm Expecting:
So far, I have set up the basic structure of the application following hexagonal architecture principles, separating the core logic from external dependencies. I've also implemented the configuration of the two state machines
Expectations:
For the messaging logic, I expect the state machine to handle sending a message, pausing its flow, and then resuming or transitioning to a new state upon receiving the corresponding response, akin to a TCP-like communication model.
For the decision making in the states REST calls to other components will be needed.
Upvotes: 0
Views: 253
Reputation: 1196
1, 2: It is not clear how u use your state machines or why you are using them. But if you are using them as orchestrators, that have access to all different layers (u mentioned business logic, messages + rest calls etc), then this is obviously violating the architecture. If not, then it should be straight-forward in which layer to put it.
2, 3: I dont see the struggle. If you dont do async calls, then the execution wont progress until you get the response. Is there some issue that i dont see?
4: For state transitions i ve only seen actions to be used. Listeners can be also used for some other actions, like for listening to errors
Upvotes: -1