Please log in to watch this conference skillscast.
One ongoing discussion among the DDD community is about clarity in how to approach long running processes.
First challenge: Implementation. There are known patterns like Saga or Process Manager, but how can these be implement properly? Having long running processes requires you to save state and to handle timeouts – but that’s just the beginning. Is a custom DSL the way to go? Should existing tools like state machines, orchestration frameworks or workflow engines be leveraged?
Second challenge: Methodology. How can end-to-end processes be implemented without violating DDD principles including the bounded context? How should responsibility be distributed? If long running processes turn out to be business processes spanning multiple days, weeks or months - how does this change the game?
In this talk Bernd will share with you a summary of his team's real-life experience at Camunda with these questions, discuss pros and cons of different approaches and provide guidance, backed by concrete code examples to illustrate alternatives.
YOU MAY ALSO LIKE:
- Modern development with Java (in London on 26th - 28th June 2017)
- F# eXchange 2018 (in London on 5th - 6th April 2018)
Long running processes in DDD
I started developing Java more than 15 years ago, when the world was still 3-tiered using ACID-Transactions. In my consulting coureer I coached countless real-life software projects and helped many many customers to implement business logic centered around long running processes, for example the order process of the rapid growing start-up Zalando, which sells clothes worldwide, or the provisioning process for e.g. SIM cards at a couple of big telecommunication companies. During that time I contributed to various Open Source workflow engines. I am also co-founder of Camunda, an Open Source company very succesful in this field. Currently I am totally enthusiastic about how business processes will be implemented in next generation architectures, and how this fit in cleanly designed domain driven systems.