Reuse has been a watch word for almost everything that has happened in system development during the last thirty years, but reuse is like cyanide; in really small portions it can be healthy, using it too much it starts doing a lot of damage, Udi Dahan claimed in his presentation giving a different perspective on business logic at this year’s DDD Exchange conference in London.
Dahan, an authority on SOA and DDD, describes how reuse was an important part of object orientation when it started to be popular, but in reality a tightly coupled mess was created using hierarchies without limitations. Then after 5-10 years component orientation came along, with reusable components as a big promise. Reuse didn’t save us that time either and then came SOA and now microservices, both highlighting reuse. From all these earlier experiences Dahan asks the question: if reuse hasn’t worked any time earlier, why will it work now?
Thoughts that reuse are a bad idea is not new and Dahan refers to Ted Neward and his contribution to the fallacies of enterprise computing to which Neward added: Business logic can and should be centralized. Dahan takes a simple rule: name must be less than 40 characters, where should we enforce this rule? Commonly we end up implementing this rule in the UI, in business logic and in the database but with several implementations a problem arises when the rule has to change. A solution Dahan has seen is to generate code from metadata, meaning the rule can be changed in one place and then all code generated, but in his experience that always fails. Basically the problem is not that the rule is implemented in several places, it’s that it’s hard to find every place so that it can be changed. A solution Dahan suggests is to use source control; have the rule in an issue and then commit all source code dealing with that rule in one commit linked to that issue. Then when the rule changes it’s very easy to find all code where the rule is implemented:
When a rule change, navigate through source control
Architecture isn’t a two-dimensional problem possible to describe in a simple diagram and Dahan refers to the 4+1 architectural view model by Philippe Kructhen which states it’s not possible to reduce an architecture to a single view, we need views that encapsulate different perspectives to deal with total complexity. For Dahan a problem with microservices is that they are all the same view, the unit of development, logic, process and physicality all collapsed into one view which he believes puts a too heavy constraint on a service.
One scenario where Dahan sees a fit for microservices is when there is a need for a quick and dirty and separately deployable implementation for testing a new business case. He notes though the importance of a rewrite if it ends up working and that the business must agree on this beforehand.
Dahan late last year took a critical look at microservices for the enterprise.
Next year’s DDD Exchange is scheduled for 10th June 2016 and registration is open.