Responsibility Driven Architecture

I'd like to introduce you to a simple term: Responsibility Driven Architecture.  Like a design pattern that you already use, it's a term to surround a concept that you probably already have, but may not have named. 

Responsibility Driven Architecture is the practice of partitioning the components of a distributed system along the lines of cohesive sets of responsibility with the goal of building simplicity and flexibility into the system design.

Systems designed from this standpoint illustrate the following attributes:

• They are easier to explain.  People understand the notion of responsibilities.  It is elemental to the way that we, as humans, organize our own work and lives.
• They are easier to maintain. If you have a well defined responsibility driving the partitioning, then changes to the requirements can be implemented relatively consistently because it is easier to understand where to write a specific change into the environment.
• Messaging is simpler: Once you accept the notion of RDA, you can remove so much of the "command and control" aspects of messages that create tight coupling between system components.  If I, as a component, trust you, as a collaborating component, to fulfill your responsibility, then I only have to communicate.  I don't need to track your progress or audit each and every error condition.  Components can trust one another.  This makes the communications simple.

I guess I've always followed the notion of responsibility driven architecture... I just didn't describe it this way.  Another way to express this idea is: an autonomous component (in a SOA or in older C-S models) is defined not by what code lives on a server or in a library or in a layer, but by what responsibilities live in the code. 

It is not a revolutionary idea.  It is born of the notion of responsibility driven design and more general patterns.  In a real sense, MVC is an RDA pattern in that the Model, View, and Controller partitions are described in terms of their responsibilities.  For all that MVC and it's bretheren are some of the oldest solution design patterns,  they are still frequently discussed.  Why?  I think it is because they fit in the RDA mold.  That makes them practical.

So when you look over your system, create a 'responsibility view' of your components.  Is it clean?  Can you clarify it?  What does it tell you?  I think you'll find this practice will help you to create better, simpler, more practical systems.

Comments

• Anonymous
  December 01, 2006
  The comment has been removed

• Anonymous
  December 05, 2006
  Nice concept. I like the idea of thinking about software through a systems perspective, where systems with clear boundaries interact with other systems, contain other sub systems, and are themselves part of larger systems. This very much sounds like how I think of contract driven programming where each service, class, module, system will specify well-defined contracts for engagement.

• Anonymous
  December 06, 2006
  A response to my prior post on Responsibility-Driven Architecture got me thinking... what is the "first