Using the IODA architecture for Java

Last week I participated in a Coding DOJO which used the IODA architecture to reduce functional dependencies within code written in Java. The IODA architecture is inspired by Ralf Westphal, who states that common architectures (like MVC, layered architecture, onion architecture …) have two things in common. They define domains of responsibility and put functional dependencies in order.

But they describe software more as a deep hierarchy of functional or behavioral dependencies [1]. The IODA architecture aims to eliminate functional dependencies. No service shall call another. This is achieved by the 4 different parts of IODA [2]:

  • Operation implements business logic. An operation is unaware of other operations. Operations use data but don’t save data.
  • Data is a structure of data
  • APIs and Frameworks are used by operations
  • Integration doesn’t implement business logic. As operations are unaware of each other, they need to be called by an integration element. An integration can also call another integration.

IODA separates the what (integration, data) from the how (operation). Furthermore IODA is self-describing. That means an integration can use another IODA structure as shown in figure 1.


figure1- The IODA structure [2]

Should I use the IODA architecture?

A good practice to write clean code is to design small classes and methods ([3], p.176). And functional dependencies lead to ever growing methods. More dependencies means tighter coupled, less flexible and especially less reusable code. IODA eliminates dependencies by forcing the creation of independent small operations. Furthermore these small modules are easy to maintain and to test. This is great but using IODA for Java means mixing object-orientation with functional programming. Usually a Java class would mix data and operations. When implementing business logic within a method – the method can grow really fast. So usually you would extract some code to another method. But then an operation (method implementing business logic) would call another operation (code snippet 1). As this is forbidden in IODA, we can introduce an integration class, that calls the operations one after another, and separate the methods from one another (code snippet 2). When they are independent, they aren’t aware from each other anymore. Using IODA for Java will lead to many small classes. As you will use so many classes within an integration, you will have to instantiate many classes to access the operations and data. Therefore many developers created static methods. So for all those who think there is nothing better than object-oriented programming, don’t use IODA. But the IODA architecture is certainly interesting as it helps to write clean code and especially makes you think in a new way. And that makes it worth a try.

public class MyClazz{
   public List<String> readAndEvaluateFile(String fileName){
    Properties defaultProps = new Properties();
    FileInputStream in = new FileInputStream(fileName);
    ...//load propertyFile and close inputStream;
    for (Map.Entry<Object, Object> entry : defaultProps.entrySet()) {
      String evaluatedString= evaluateProperty((String) entry.getKey(), (String) entry.getValue());
   public String evaluateProperty(String key, String value){

code snipped 1- method delegates to method

public class MyIntegratiionClass{
   public List<String> readAndEvaluateFile(String fileName){
      MyOperationClass operatioClass= new MyOperationClass();
      Properties properties= operationClass.readPropertyFile();
      return operationClass.evaluateProperty(properties);
public class MyOperationClass{
   public Property readPropertyFile (String fileName){
      Properties properties= new Properties();
  …// load propertyFile and close inputStream
  public List<String> evaluateProperty(Properties properties){
  for (Map.Entry<Object, Object> entry : properties.entrySet()) {

code snippet2 – transforming methods to operations




[1]Jan Stenberg(2015): Introducing IODA Architecture in

[2] Ralph Westphal (2015): The IODA Architecture in

[3]Robert C. Martin (2008): Clean Code A Handbook of Agile Software Craftsmanship


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s