Download to read offline
Uploaded byThomas Heinrichs
Combining Orchestration and Choreography for a Clean Architecture
- Combining orchestration and choreography can provide a clean architecture for software systems. Orchestration uses a command-based style while choreography uses an event-driven communication style. - Writing integrations following clean and hexagonal architecture principles increases maintainability, testability, and flexibility. This involves organizing the architecture into layers with adapters translating between systems and no outgoing dependencies from the domain core. - Applying domain-driven design patterns like bounded contexts and domain events can further improve decoupling when combined with orchestration and choreography. Key practices include throwing events for data changes and only using them for communication outside bounded contexts.
Technologyā¦
More Related Content
Similar to Combining Orchestration and Choreography for a Clean Architecture
Combining Orchestration and Choreography for a Clean Architecture
- 1. Combining Orchestration and Choreography fora Clean Architecture Thomas Heinrichs
- 2.
- 3. About 12 Team Members 8 Projects 2020 Founded Training BPMN, DMN& Architecture Training Consulting Flexible remote consulting Workshops Proof of concepts & Quickchecks Professional Services Custom development projects
- 4. What to expect Reviewingthe low code approach How does a low code implementation look like? What are advantages and downsides? Writing clean integrations What is clean architecture? How to implement a hexagonal architecute? How to write engine independent code? Scaling up What is Domain Driven Design? What is Choreography? What are the best practices for domain events?
- 5. Letās talk about Pizza! ā¦and low-code
- 6.
- 7. Reviewing the lowcode approach ADVANTAGES ā¢ Rest Connectors enable non-technical users to create and modify automated processes ā¢ Calling external services with the low code approach reduces development time and costs ā¢ Lowers the barrier to entry for process automation DISADVANTAGES ā¢ Tighter coupling and violation of the separation of concerns principle due to Connectors ā¢ Can easier lead to a vendor-lock-in problem ā¢ Need for a greater dataset flow through the process instance ā¢ Misuse of the BPMN standard
- 8. Relying on Connectors -it depends on the use case DO IT YOURSELF ā¢ Simple ā¢ Local automations with little criticality ā¢ No governance or quality assurance needed GUIDED ā¢ Medium complexity ā¢ Medium cirticality ā¢ Some governance required ā¢ Some guidance necessary PROFESSIONAL DEVELOPMENT ā¢ High complexity ā¢ High criticality ā¢ Complicance and regulatory requirements ā¢ Version control ā¢ Automated testing
- 9. Use domain specific Connectors Sendingan SMS Example Protocol level Domain level
- 10. Writing clean integrations āAtits core, clean architecture divides a software system into parts, with each part having a specific responsibility and clear dependencies.ā Definition: Clean Architecture Benefits: Increased Maintainability, Testability, Scalability, Flexibility, Collaboration
- 11. Writing Hexagonal Integrations Ports andAdapters ā¢ We organize the hexagonal architecture into layers ā¢ The outermost consist of adapters that translate between the application and other systems No outgoing dependencies ā¢ All dependencies point toward the center ā¢ The Domain has no dependency towards the Use-Case or an Adapter Benefits ā¢ Truly technology neutral application core ā¢ Easily adaptable to new technical surroundings ā¢ Far easier maintainable Integration Component Using Hexagonal Architecture
- 12.
- 13.
- 14.
- 15. Demo ā Implementation ofa hexagonal architecture
- 16. Scaling up With aclever mix of a choreographed event-based style and an orchestrated command based style you can reach the level of decoupling you aim for!
- 17. What is Choreography? ļUsesevent-driven communication Event = Something happended in the past. It is a fact. Sender does not know who picks up the event. Pizza Place You āHey ā I am hungry!ā
- 18. Applying Domain DrivenDesign āDomain Driven Design is an approach to software development that centres on programming a domain model that has a rich understanding of the processes and rules of a domain.ā Martin Fowler
- 19. Bounded Context DDD devidesup a large system into Bounded Contexts, which can have a unified model Bounded Contexts have both, unrelated concepts but also some shared ones Acts as a central patterns and allows to create dependencies based on the domain logic
- 20.
- 21.
- 22. Throwing the rightdomain events - Best Practices Use clean names and do not reuse events Throw events when you manipulate data (e.g. create, update, delete) Do not expect something in return after having thrown the event Try to use it only for communication out of the bounded context
- 23. Key Takeaways Design yourservices technology and engine neutral Use Domain Events for communication outside the bounded context Gain better maintainability by using a hexagonal architecture For an ideal decoupled architecture use a clever mix of a choreographed event-based style and an orchestrated command based style communication
- 24. Thanks for listening! ThomasHeinrichs BPM Consultant
Editor's Notes
- #22Ā Show service which throws a Domain Event Mention that there is the Kafka Out Adapter which published the actual event We are having a separate satisfaction miranum service Consumes event Starts a process via a message Run through example Frontend start take-away Open Operate show instance moving through process Show created task in TaskList