Hi Ralf, I am currently trying to learn Flow Design, IODA, IOSP etc. with your book Flow Design Programming with ease and with your colleague Stefan Lieser´s book Flow Design. I also read your articles in the DotnetPro magazine and investigating the github repos of you and Stefan. I find your ideas interesting, and I am excited if I can introduce these concepts in our brown field projects (more or less).
But I am little bit disappointed about the less reaction of the community here and your other posts. It would be great to see if others could implement these concepts in their business applicatons successfully and what challanges they had to solve.
It would be great to have others to talk about questions, ideas etc. Is there any community place where IODA/IOSP is discussed?
Regarding Sleepy Hollow Architecture and the Interactors, it seems that you and Stefan have a different definition of a flow design based software structure. In Stefan´s book (page 177) it seems that the Interactors class is that what here in your post is the Processor. So Stefans Interactors is integrating Domain and Provider. His Interactors is not integrating UI. In Stefans architecture he has a Controller class that integrates UI and Interactors.
Can you give some clarification of my confusion please?
Are you both still working together or do you have different opinions?
Glad to hear you're delving into Flow Design and IODA!
Why isn't the community more interested in IODA, IOSP etc.? Because people are drowned by the older principles/concepts like SOLID or Hex/Clean Architecture. Over time they have got so much more visibility, that's hard to match. Stefan and I were always focused on the DACH market.
Check out the Clean Code Developer community on Discord: https://discord.gg/9p9YX7T8 (link valid until 25.8.23). We are excited to hear about your insights and questions there.
Sleepy hollow is "on top of IODA". It came later.
The terminology in IODA has changed. In the beginning the integration strata were called Controller and Interactor. Later I changed Controller to Application and Interactor to Processor - and Stefan kept the former.
I don't mind that much. All terms have their merits:
- Application: I find this a more general term; Controller is more suggestive of a web service.
- Processor: I find this a more general term. Interactor is alluding to the Clean Architekture and is pointing at where "things really happen" in an interaction diagram used in Slicing.
Stefan and I parted ways some years ago. He's actively promoting Flow Design with his CCD academy trainings; I've retreated to Bulgaria and am not really actively/heavily involved in Clean Code Development anymore. Sometimes I write about it in this blog. But mostly I'm concerned with matters not related to CCD. I'm happy with concepts developed from 2008 until now.
Why two books? Because this topic (like any other) deserves different points of view.😁 We are sharing most opinions on this, but we're also differing in some aspects.
And any additional book on Flow Design of course is welcome, too😁 Why not continue the development of this "art"?
Hi Ralf, thank you for this good article. One question, as all found links to the discord group are expired. Is that community still existing and open to join?
Thank you for your quick reply and the clarifications, and of course for the discord invitation, I appreciate this very much!! Writing a book was not in my mind (yet :D). First I need to learn and gather experience in practice of our brown field project. But the hardest part will be to point our architects and developer team to these concepts. It would be nice to hear/read success stories, it would help as an argument.
Coming from the "True agility needs event sourcing" thread and arrived reading this one due to your hint. Very interesting approach and I might try to design the inner world of a slice like this. What would help me is to see a recursive example of IODA. When a larger cell is dependent of a smaller cell, is the smaller cell then called via a provider?
Exactly. I wanted to play around with it a bit and asked Cursor to implement the example from your article and added another "software cell". It converts the expenses of the text file which are in different currencies now to EUR and queries a (mocked) API for that.
Is this the way you would structure it hierarchically? I repeated the structure of a full IODA cell below the existing. So there is basically a dependency, but the core remains pure.
I looked at your repo. Very IOSP! I like it! Faithful implementation of IODA.👍
But I fail to see a second software cell. Maybe you can draw a diagram with your cells and the adapters? Put it in the repo as a kind of documentation.
Thanks for having another look. And also your graphs really helped here. That's exactly why I built his example. Because, I don´t know I don´t know if I fully got it.
From the diagrams in your article I took away somehow that there is only ever one core in one software cell. But this is not the case.
So the code style with nested elements is still IODA how you think about it? But a software cell can contain multiple functional elements all contributing to the life of the cell.
The Free World Theory substack is taking off. Currently have almost 1,000 subscribers, and more and more people are recommending it. Thanks for the early support!
Hi Ralf, I am currently trying to learn Flow Design, IODA, IOSP etc. with your book Flow Design Programming with ease and with your colleague Stefan Lieser´s book Flow Design. I also read your articles in the DotnetPro magazine and investigating the github repos of you and Stefan. I find your ideas interesting, and I am excited if I can introduce these concepts in our brown field projects (more or less).
But I am little bit disappointed about the less reaction of the community here and your other posts. It would be great to see if others could implement these concepts in their business applicatons successfully and what challanges they had to solve.
It would be great to have others to talk about questions, ideas etc. Is there any community place where IODA/IOSP is discussed?
Regarding Sleepy Hollow Architecture and the Interactors, it seems that you and Stefan have a different definition of a flow design based software structure. In Stefan´s book (page 177) it seems that the Interactors class is that what here in your post is the Processor. So Stefans Interactors is integrating Domain and Provider. His Interactors is not integrating UI. In Stefans architecture he has a Controller class that integrates UI and Interactors.
Can you give some clarification of my confusion please?
Are you both still working together or do you have different opinions?
Why two books and not one book together?
Regards,
Christian
Glad to hear you're delving into Flow Design and IODA!
Why isn't the community more interested in IODA, IOSP etc.? Because people are drowned by the older principles/concepts like SOLID or Hex/Clean Architecture. Over time they have got so much more visibility, that's hard to match. Stefan and I were always focused on the DACH market.
Check out the Clean Code Developer community on Discord: https://discord.gg/9p9YX7T8 (link valid until 25.8.23). We are excited to hear about your insights and questions there.
Sleepy hollow is "on top of IODA". It came later.
The terminology in IODA has changed. In the beginning the integration strata were called Controller and Interactor. Later I changed Controller to Application and Interactor to Processor - and Stefan kept the former.
I don't mind that much. All terms have their merits:
- Application: I find this a more general term; Controller is more suggestive of a web service.
- Processor: I find this a more general term. Interactor is alluding to the Clean Architekture and is pointing at where "things really happen" in an interaction diagram used in Slicing.
Stefan and I parted ways some years ago. He's actively promoting Flow Design with his CCD academy trainings; I've retreated to Bulgaria and am not really actively/heavily involved in Clean Code Development anymore. Sometimes I write about it in this blog. But mostly I'm concerned with matters not related to CCD. I'm happy with concepts developed from 2008 until now.
Why two books? Because this topic (like any other) deserves different points of view.😁 We are sharing most opinions on this, but we're also differing in some aspects.
And any additional book on Flow Design of course is welcome, too😁 Why not continue the development of this "art"?
Hi Ralf, thank you for this good article. One question, as all found links to the discord group are expired. Is that community still existing and open to join?
Come and join the server: https://discord.gg/MNRYmGJK
Thank you for your quick reply and the clarifications, and of course for the discord invitation, I appreciate this very much!! Writing a book was not in my mind (yet :D). First I need to learn and gather experience in practice of our brown field project. But the hardest part will be to point our architects and developer team to these concepts. It would be nice to hear/read success stories, it would help as an argument.
Coming from the "True agility needs event sourcing" thread and arrived reading this one due to your hint. Very interesting approach and I might try to design the inner world of a slice like this. What would help me is to see a recursive example of IODA. When a larger cell is dependent of a smaller cell, is the smaller cell then called via a provider?
You mean a software cell? They are meant to represent distributed parts of code, usually a process. (But could be a thread or a whole network.)
So, when you think of a software cell containing (!) another then, yes, communication requires a provider-portal pair.
But an encompassing cell would reveal at least two cells when zooming in, eg a client and a server.
Exactly. I wanted to play around with it a bit and asked Cursor to implement the example from your article and added another "software cell". It converts the expenses of the text file which are in different currencies now to EUR and queries a (mocked) API for that.
Is this the way you would structure it hierarchically? I repeated the structure of a full IODA cell below the existing. So there is basically a dependency, but the core remains pure.
https://github.com/SBortz/IODA-ExpenseSplitter
I´d love to get your feedback on this.
I looked at your repo. Very IOSP! I like it! Faithful implementation of IODA.👍
But I fail to see a second software cell. Maybe you can draw a diagram with your cells and the adapters? Put it in the repo as a kind of documentation.
It's below the ExpenseSplitter. ExpenseSplitter depends on CurrencyConverter.
I see what you mean. But that's not a new software cell in my view. I don't think you need to wrap it up like that.
Sure, the currency conversion stuff is neatly tugged away behind its own processor. Since it's in the same process, though, no need to call it a cell.
I really encourage you to draw dependency diagrams like this: https://arteam.notion.site/Expense-Splitter-IODA-Architecture-2429ef08546480aca933ef3c47201c88?source=copy_link
Just because there are multiple providers does not mean there are multiple cells.
Cells are really reserved for hosting logic on different threads or processes. They are a matter of distribution, not order.
Thanks for having another look. And also your graphs really helped here. That's exactly why I built his example. Because, I don´t know I don´t know if I fully got it.
From the diagrams in your article I took away somehow that there is only ever one core in one software cell. But this is not the case.
So the code style with nested elements is still IODA how you think about it? But a software cell can contain multiple functional elements all contributing to the life of the cell.
Hey Ralf, how's it going?
The Free World Theory substack is taking off. Currently have almost 1,000 subscribers, and more and more people are recommending it. Thanks for the early support!
Hope everything is well with you.
ch