Clean Code in a SOA world: The Single Responsibility Principle

pocketknife

The Single Responsibility Principle (SRP) states that a class should do just one thing. And thus should have only one reason to change. This is usually a good idea. We should follow this principle when designing our SOA artifacts as well. We already achieve some responsibility segregation by using different artifacts for different purposes: XSLT or XQuery scripts for transformations, routing tables for wiring systems, rule languages for business rules, BPEL for process definitions, and so on. But we could still violate the SRP. The more powerful the language, the higher the risk of doing something in the wrong place or at the wrong level of abstraction. For example, you could specify a transformation or something not process-related directly in your BPEL code. Or you could misuse XSLT to achieve some sort of side effect (perhaps using Java invocations). So whenever you have the feeling your SOA artifact does more than one logical thing (or operates at different levels of abstractions, see Single Level of Abstraction principle), try to split it into multiple pieces. This will result in more, but smaller and better focused artifacts. You should have no problems finding an appropriate name for your artifact. By the way, I like to avoid inline XML Schema definitions in my WSDL files, and SRP is one good explanation for that.

This article is part of my series Clean Code in a SOA world.  Picture: My Swiss Army Knife

You may also like...