IODA - Architecture Ralf Westphal - Anyone use it also?
-
I use IODA architecture since the very beginning, nearly 10 years now. I develop SW more than 30 years as a profi. It is the first approach/technique, that offers the option to produce reusable, small classes like "lego building blocks". It is ortogonal to other best practices like CleanCode, DRY and other. It has a strong impact on unit testing: Unit testing will be easy. The reason is simple: IODA was designed to reduce dependencies between classes to a minimum. I - Integration - calls all other, but does not contain logic or data O - Operation - contains logic, just work with data, do not know other operations or integrations D - Data - holds the data and knows/deals only about itself and its childs. No operations here. A - API - Application Interfaces - To deal with the environment or to provide general functions like data validation and other stuff All of these classes are devolped by the project. Standard-Libraries can be found below this code. If you then divide the Operations in "IO operations" and "other operations" you get the following: IO_operation "reader" reads "data_ger", operation "translator" translates "data_ger" to english data "data_eng" and then the IO operation "View_data" presents it to the user. And the integrator "TextManager" has a method like
void viewAsEnglish(int textIdGer, string readLang = "ger")
{
var data_ger = reader.Read(textIdGer, readLang);
var data_eng = translator.Translate(data_ger, "eng");dataViewer.View(data_eng);
}After longer practice you will automatically think in these four types, when creating a new class. And yes, it will work fine in real projects. Now lets start discussion about it, if you want. **Links** Detailed description: https://www.infoq.com/news/2015/05/ioda-architecture/[^] Bigger sample project (documentation only in german, sorry) GitHub - jpr65/VersandEtiketten: This is a reference projekt for IODA and also a developer test ticket. Only in german, possible later also in english.[^] ** Images ** IODA - Principle Diagram
-
I use IODA architecture since the very beginning, nearly 10 years now. I develop SW more than 30 years as a profi. It is the first approach/technique, that offers the option to produce reusable, small classes like "lego building blocks". It is ortogonal to other best practices like CleanCode, DRY and other. It has a strong impact on unit testing: Unit testing will be easy. The reason is simple: IODA was designed to reduce dependencies between classes to a minimum. I - Integration - calls all other, but does not contain logic or data O - Operation - contains logic, just work with data, do not know other operations or integrations D - Data - holds the data and knows/deals only about itself and its childs. No operations here. A - API - Application Interfaces - To deal with the environment or to provide general functions like data validation and other stuff All of these classes are devolped by the project. Standard-Libraries can be found below this code. If you then divide the Operations in "IO operations" and "other operations" you get the following: IO_operation "reader" reads "data_ger", operation "translator" translates "data_ger" to english data "data_eng" and then the IO operation "View_data" presents it to the user. And the integrator "TextManager" has a method like
void viewAsEnglish(int textIdGer, string readLang = "ger")
{
var data_ger = reader.Read(textIdGer, readLang);
var data_eng = translator.Translate(data_ger, "eng");dataViewer.View(data_eng);
}After longer practice you will automatically think in these four types, when creating a new class. And yes, it will work fine in real projects. Now lets start discussion about it, if you want. **Links** Detailed description: https://www.infoq.com/news/2015/05/ioda-architecture/[^] Bigger sample project (documentation only in german, sorry) GitHub - jpr65/VersandEtiketten: This is a reference projekt for IODA and also a developer test ticket. Only in german, possible later also in english.[^] ** Images ** IODA - Principle Diagram
I haven't seen this architecture before. Seems interesting but there is one thing I don't get:
Ralf Peine 2023 wrote:
I - Integration - calls all other, but does not contain logic or data O - Operation - contains logic, just work with data, do not know other operations or integrations
If I need to to implement something like "if operation1 fails do operation2", where do I place the logic? I cannot place it in the integration units (cannot contain logic or data) and cannot place it in one of the operations (do not know other operations). What is the solution?
Mircea
-
I haven't seen this architecture before. Seems interesting but there is one thing I don't get:
Ralf Peine 2023 wrote:
I - Integration - calls all other, but does not contain logic or data O - Operation - contains logic, just work with data, do not know other operations or integrations
If I need to to implement something like "if operation1 fails do operation2", where do I place the logic? I cannot place it in the integration units (cannot contain logic or data) and cannot place it in one of the operations (do not know other operations). What is the solution?
Mircea
Yes, that's some important point. You may add minimal logic into the integrator to set switches for the workflow. However, the decision why a switch is set should again be made in an operation, if it is not a simple true/false decision. It is ***allowed*** to put logik in integrators, sometimes it is easy for the moment, but this leads to technical debt and is sometimes difficult to test. Especially while doing hotfixes, you will break the IODA principles, and this is ok, for the moment. The more you stick to the IODA principles, the more testable and reusable the code will be, that you create.
-
I use IODA architecture since the very beginning, nearly 10 years now. I develop SW more than 30 years as a profi. It is the first approach/technique, that offers the option to produce reusable, small classes like "lego building blocks". It is ortogonal to other best practices like CleanCode, DRY and other. It has a strong impact on unit testing: Unit testing will be easy. The reason is simple: IODA was designed to reduce dependencies between classes to a minimum. I - Integration - calls all other, but does not contain logic or data O - Operation - contains logic, just work with data, do not know other operations or integrations D - Data - holds the data and knows/deals only about itself and its childs. No operations here. A - API - Application Interfaces - To deal with the environment or to provide general functions like data validation and other stuff All of these classes are devolped by the project. Standard-Libraries can be found below this code. If you then divide the Operations in "IO operations" and "other operations" you get the following: IO_operation "reader" reads "data_ger", operation "translator" translates "data_ger" to english data "data_eng" and then the IO operation "View_data" presents it to the user. And the integrator "TextManager" has a method like
void viewAsEnglish(int textIdGer, string readLang = "ger")
{
var data_ger = reader.Read(textIdGer, readLang);
var data_eng = translator.Translate(data_ger, "eng");dataViewer.View(data_eng);
}After longer practice you will automatically think in these four types, when creating a new class. And yes, it will work fine in real projects. Now lets start discussion about it, if you want. **Links** Detailed description: https://www.infoq.com/news/2015/05/ioda-architecture/[^] Bigger sample project (documentation only in german, sorry) GitHub - jpr65/VersandEtiketten: This is a reference projekt for IODA and also a developer test ticket. Only in german, possible later also in english.[^] ** Images ** IODA - Principle Diagram
Like perhaps everything along these lines it has some utility as long as it is not taken as an absolute. I certainly do not want to see every single operation in a million line application decomposed like this. For example I have written reports at various times in various languages and attempting to decompose them often lead to nothing but making it harder to understand the whole. Then after that one must consider in standard business programming of maintaining an application over years with multiple changes in employees is this likely to be rigorously maintained? If it isn't then doesn't it just devolve into what the original code might have looked like the first place?
-
I use IODA architecture since the very beginning, nearly 10 years now. I develop SW more than 30 years as a profi. It is the first approach/technique, that offers the option to produce reusable, small classes like "lego building blocks". It is ortogonal to other best practices like CleanCode, DRY and other. It has a strong impact on unit testing: Unit testing will be easy. The reason is simple: IODA was designed to reduce dependencies between classes to a minimum. I - Integration - calls all other, but does not contain logic or data O - Operation - contains logic, just work with data, do not know other operations or integrations D - Data - holds the data and knows/deals only about itself and its childs. No operations here. A - API - Application Interfaces - To deal with the environment or to provide general functions like data validation and other stuff All of these classes are devolped by the project. Standard-Libraries can be found below this code. If you then divide the Operations in "IO operations" and "other operations" you get the following: IO_operation "reader" reads "data_ger", operation "translator" translates "data_ger" to english data "data_eng" and then the IO operation "View_data" presents it to the user. And the integrator "TextManager" has a method like
void viewAsEnglish(int textIdGer, string readLang = "ger")
{
var data_ger = reader.Read(textIdGer, readLang);
var data_eng = translator.Translate(data_ger, "eng");dataViewer.View(data_eng);
}After longer practice you will automatically think in these four types, when creating a new class. And yes, it will work fine in real projects. Now lets start discussion about it, if you want. **Links** Detailed description: https://www.infoq.com/news/2015/05/ioda-architecture/[^] Bigger sample project (documentation only in german, sorry) GitHub - jpr65/VersandEtiketten: This is a reference projekt for IODA and also a developer test ticket. Only in german, possible later also in english.[^] ** Images ** IODA - Principle Diagram
I see ETL: extract, translate, load. Your sample "integrator" looks more like a "translator". While my "data" may not have methods, it resides in a repository that does: add, delete, update, query. Data as another object. The methods represent an "API". And I have "operations" that depend on other operations: "distance" calculators for anything that needs to calculate a distance (in pixels, paces, yards, or feet); or an angle; or "a collision detector" while moving. I don't disagree with the architecture, but things aren't that clear cut.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
I see ETL: extract, translate, load. Your sample "integrator" looks more like a "translator". While my "data" may not have methods, it resides in a repository that does: add, delete, update, query. Data as another object. The methods represent an "API". And I have "operations" that depend on other operations: "distance" calculators for anything that needs to calculate a distance (in pixels, paces, yards, or feet); or an angle; or "a collision detector" while moving. I don't disagree with the architecture, but things aren't that clear cut.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
This example and the dokumentation are very small. Please read the detailed description of Ralf Westphal. "Translation" is what the integrator manages, and "integration" is the type of the class in the meaning of IODA. Reason for IODA approach is the following "Functional dependencies are evil!" Only the integrator classes are allowed to call operation classes. So, in an ideal world, you have no functional dependencies.
-
This example and the dokumentation are very small. Please read the detailed description of Ralf Westphal. "Translation" is what the integrator manages, and "integration" is the type of the class in the meaning of IODA. Reason for IODA approach is the following "Functional dependencies are evil!" Only the integrator classes are allowed to call operation classes. So, in an ideal world, you have no functional dependencies.
If you want people to appreciate the benefits of this approach, write an article, hosted here on Code Project showing a non-trivial application created using these techniques. I find myself deeply distrustful of prescriptive ways of working when they are presented as absolutes (e.g. "Functional dependencies are evil!"). No approach is 100% perfect and, generally, there are always be exceptions to the absolutes that are the driving reason for a new way of working.
