Solid Architecture: S.O.L.I.D Principles

Domain Driven Design (DDD) and Service Oriented Architecture (SOA) can basically be defined as aggregate functions of principles, patterns, and most importantly Object-oriented concepts. In order to build a highly scalable and reliable architecture, it is very important for us to follow these important design patterns, and when they are coupled with a set of good principles, results in a great software. One such set of rules that should not be overlooked are S.O.L.I.D principles, first coined by Robert C. Martin.

There are plenty of resources available on the Internet on these principles. So far, I really liked Steven Bohlen’s video presentations on dimecasts.net.

Also, I recommend the following books to get a good picture on building overall good software.

English Manual for Technologists

For those of us who are not good technical writers, here is a great book that continues to help me a lot. It is by William Strunk Jr., and is called ‘Elements of Style’. You can order it from Amazon if you like reading a hard book, and this book is online on bartleby.

Rules Engines

Rules Engine can be defined as a framework that is used to manage and automate business rules. It is very useful to have such a framework in place specially when these business rules need to be modified frequently. Often, we as software architects need to design our applications to handle such frequent change in business rules. There are several rules engines available in the market. Some of the rules engines  available are;

.Net

• Biztalk Server
• ILog Rules for .Net

Java

• Jess
• Jboss Rules
• ILog JRules

Ruby

• Ruleby
• Ruby Rools

Most of these engines, or frameworks use Dr. Charles Forgy’s Rete Algorithm. Rete is Latin for Net or network. It is a pattern matching algorithm comprising of rule compilation and rule execution. Before adopting this in your enterprise, every Architect must understand this algorithm to know the various architectural implications that it can have on the overall system like performance, scalability, etc., Also, just because you implement a rules engine, it does not mean that you can put all your business requirements and rules inside it, as some of the business rules cannot be expressed. Most often, these business rules cannot be expressed by the business users, and have to be coded by programmers.

Ethics in software engineering

This topic has a lot of importance and relevance in today’s world, which is why it is my first post on my blog. Software engineering is going through lots of cycles and changes. The way I used to do things 10 years ago is no longer true. There are several changes in terms of culture, with the advent of technology enablers like cloud computing, architectural patterns like service oriented architecture, etc., but the fundamentals never change.

One such fundamental area is ethics in software engineering. It holds a lot of value in the way we practice software engineering, design, and architecture, but is sometimes ignored. There is a code of ethics in software engineering and professional practice jointly approved by ACM and IEEE. Here is a short version of this code from the ACM:

If you are interested in the longer version, you can visit the ACM site; Full version. While all the points above are important, point 7 is a more interesting point which warrants a separate post.

Further, each company has its own demands and requirements when it comes to ethics. I urge every IT manager to use this code as a basis to draft a more relevant and specific code of ethics, that suits his engineering practices. He then needs to educate his team on the benefits of the code. It is a moral responsibility of every software engineer to adhere to these principles.