Why is it that we love objects in the real world but not in the virtual world? We all love the ignition key interface for our cars, some fortunate few can afford a push button start and some may just prefer to hot-wire, in which case they are mostly others cars! As developers we are experts in hot-wiring. If the car in the example did not conceal its wires and did not provide a key interface the only and easiest way to start it would be to hot-wire it, and you will be successful only if you find the right wires! This is the state of the objects that we create in our software today, with all the getters and setters exposing the internals of the objects. Just imagine the whole car with all the internals of all its parts exposed, it would be a big ball of wires and metal pieces. After years of testing I’m sure you can drive it around but you wouldn’t want one for yourself because you do value elegance and other things like maintenance and security.

As developers we have the job of translating the business language into something that can be executed. If plain English were executable we would not need coders. Fortunately or unfortunately technology is not there yet. To execute a language like English you need technology that can deal with ambiguity and derive execution contexts dynamically and in a reliable way. Such technology is in its very early stages.

Business language or more popularly known in the Domain Driven Design community as the Ubiquitous Language is the language spoken by the business people to describe processes and rules of the domain. The developers then encode it into executable code. When the business analysts need clarifications or request changes to the implementation the developers search and decode it to the business language. The value is greatest when any developer can do the encoding and decoding. In a few circles the obvious value here is known as the Bus-Hit-Factor. Although macabre it does clarify the point quite well. Bus-Hit-Factor is a number, which indicates the maximum number of developers that can be hit by a bus before the business starts to panic. If the dependency on the developer is high then such a business would panic even if just one developer was hit by a bus, that means the Bus-Hit-Factor is one. We can understand that the company must value its employees but this is ridiculous. A successful business must have a high Bus-Hit-Factor.

So how do you increase the Bus-Hit-Factor of your code base? One sure way is by keeping the code base intuitive and readable that is by keeping the code base closest to the business language. Another practice that can increase the Bus-Hit-Factor greatly is the test coverage. If the test coverage is high other developers will have the courage to make changes to the code base freely without worrying about breaking any existing functionality. To increase the test coverage the code must be testable. The code is testable if the cyclomatic complexity is kept to a minimum. Distributing the code (business can lower Cyclomatic complexity rules) among entities. You may argue that having all the code in one place is more readable, if you extracted the piece of code into a method with meaningful name you still have everything in the same place telling you exactly what that piece of code will do and in what context. Thus avoiding need for comments. You have self-documenting code as well.

A good domain model amplifies re-usability. When we say domain object or entity we are really talking about a context for rules to operate within. A domain object can be told what to do and they will know whom to talk to get the work done, since they have the necessary data(the context) with them. This is what the Law of Demeter also states “Do not to talk to strangers”. So in effect what we will have are smart objects that know what to do. Other modules working in the same context can look for the functionality in these smart objects thus making it easier to locate the functionality. This removes unrelated or unintuitive Util or Service class dependencies. Domain objects are free from needless property getters and setters due to this. State transitions are encapsulated in meaningful business functions in the domain objects and therefore must be the ones validating them. Domain objects are therefore also the source for business events. These events can be published and then consumed by subscribers such as transaction databases, event recording databases and reporting/analysis databases.