When we speak about orchestration we should think of conductor in philharmonic orchestra. Basically His role is to show rhythm to all musicians. In the other hand “Swan Lake” don’t need conductor for dancers. They know when its their part, and which steps they need to do. Its all because of choreography.
You can find a lot of examples which use this two fundamental ways of keeping processes in correct order. You can find them in Event Driven Architecture, Microservices, CQRS, Hexagonal Architecture and so on. In my opinion we should talk about them more- to understand them and use them in correct and proper way.
Sometimes you need to do one step back to be able to do two steps forward. I would like to show you advantages and disadvantages of orchestration and choreography. I would like to show you when to use them and finally – how to do it effectively.
My talk will be held at 2PM on App Arch Track. You can find full schedule here. Original talk description here.
4Developers is an interdisciplinary festival for developers that consists of diverse tracks led in small groups. The idea of the event is to create a space that promotes the activity of specialists – the exchange of knowledge and experiences of IT community. However, 4Developers is so much more than just lectures. It is also a great opportunity to step outside the lecture zone and meet with world class specialists and enthusiasts of the IT world in a relaxed atmosphere.
My talk: Evolving Architecture
During development phase its very easy to cross the design boundary – we want to take care about all possibilities and potential changes that can happen in our project. On the other hand when we are under the time pressure we take shortcuts which could in the end increase cost of even simple changes. How to deal with “overdesign”? How (at the same time) don’t close for improvements and changes? When we should make crucial technical decisions and when accept technical debt? This session is about true stories, mostly about huge mistakes, but also sometimes about decisions which in the end were very sucessfull. The session for all who don’t want to end up with project that need’s to be rewritten to add a new button. The session for all who cares.
Hotel Sangate Airport *** 17 Stycznia Street No. 32 02 – 148 Warsaw
Here you can find more info about this great event 🙂
Description
During development phase its very easy to cross the design boundary – we want to take care about all possibilities and potential changes that can happen in our project. On the other hand when we are under the time pressure we take shortcuts which could in the end increase cost of even simple changes. How to deal with “overdesign”? How (at the same time) don’t close for improvements and changes? When we should make crucial technical decisions and when accept technical debt? This session is about true stories, mostly about huge mistakes, but also sometimes about decisions which in the end were very successful. The session for all who don’t want to end up with project that need’s to be rewritten to add a new button. The session for all who cares.
Still not sure?
This talk is a result of last 6 years of my professional experience with more than 10 projects. And within these projects I was able to see bad things and of course … really bad things. After each of them I’d got a feeling that I will never make the same mistake again. What I’m really proud of – I kept that promise! I was making new mistakes each time 🙂 I dealt with “over-designed” systems and “under-designed”. I’ dealt with “company frameworks” and “our own solution!”.
I would like to do retrospective about all good and bad choices that have been made in all of these projects. I really do believe that with every mistake that has been made we can be closer to deliver better software with more fun and excellence…
There is one great thing about “standard” design patterns (book by gang of four): each of them is not only a description of implementation and its name, but also description of pros&cons. This is in my opinion the most important thing about them. You have solutions with ready on plate information about their limits and possibilities. Knowing the limits gives you much more power to deliver better and more flexible software. It’s not only about delivering solutions. It’s about providing software that can be adopted to needs, however without wasting time when it’s not necessary.
And this talk is about my vision how to find this balance in real world projects.
Afterwords
I did very similar talk a few weeks ago in Gliwice. This time it will be slightly different with lot of improvements.
