Long live the domain, said the Enterprise! Date:   Monday , February 08, 2010 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. It is not wise to invest in an upfront domain-modeling phase that will represent the business perfectly. In the real world where everything is infinite or infinitesimal, we are able to carry on with our day to day activities despite the limited visibility, making appropriate abstractions and assumptions and as and when new discoveries are made we simply adjust our understanding. Therefore the key issue to focus here is to keep the cost of change and the maintenance of a reliable model small. This can be achieved easily with the right choice of technology (good OOP language with strongly typed system) and a continuous process to integrate and test small increments to the domain quickly and frequently. People use OO languages for their runtime services more than their OO features. Most code bases follow the Big-Ball-Of-Mud approach and are just a large modularized script, which is no different to coding in C or PL/SQL. It seems to me that developers don’t use C or PL/SQL because they don’t like grappling with pointers, allocating/deallocating memory or being tied to a particular database. Java maybe mainstream but not OOP. Big-Ball-Of-Mud architecture is no doubt the stereotypical and successful architectural style today but not for building great software that can withstand the test of time. A paper found here http://www.laputan.org/ mud/ discusses the Big-Ball-Of-Mud architecture in great detail and can help understand the forces behind its proliferation and success. It also discusses the symptoms and suggests appropriate remedies. In conclusion software applications are designed to solve a problem in a domain in the real world. Therefore we must model the virtual world closely to the real world. An ubiquitous language implemented by the developers and spoken by the analysts brings a lot of consistency and clarity in discussing the problem space. Businesses or the stakeholders are always trying to reduce their risk on investment and for that reason the Bus-Hit-Factor of the code base should be maintained athigh levels. A good domain model improves testability, readability and reusability, unlike in Big-Ball-Of-Mud architecture where testing and comprehension becomes difficult. An incremental and evolutionary approach to building the domain model will result in an adequate and reliable model. Long live the domain, said the Enterprise. The author of the article is Donny Biddappa, the Engineering Manager, Eka Software Solutions.