Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Udi Dahan on Reuse in Business Logic and Microservices

Udi Dahan on Reuse in Business Logic and Microservices

This item in japanese


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.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • What's in a Name?

    by Sam Siddiqi,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Interesting idea about using source control to trace all usages of a rule. One could also annotate the code, I suppose, with perhaps a little bit more effort.

    I don't think Name is a convincing example. A solid value object set which represent the basic core concepts of a business domain are very helpful. I've noted that such objects have a pretty regular way of mapping across concerns. In my Java EE stack: a custom JSF composite to render, a BVF validator to validate at UI and JPA levels, a Hibernate UserType to map to persistence, and so on.

    The core logic is a part of the value object, that a Name is a string with no more than 40 chars. Invoke from the validation logic from anywhere...the important thing is that the concept is established and treated like a first class citizen of the code. Everything else tends to follow...

    Yes, changing the rule may have impacts throughout the code base, but it should be predicable, at least in such cases.

  • Sharing validation

    by Onam Chilwan,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Would be nice for some more complex examples and how such logic should be distributed among multiple microservices for instance.

  • Not reuse, urbanism...

    by Erik Gollot,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Just to say that in terms of IS architecture I hate "reuse". The problem is urbanism, so responsibility, not reuse. And urbanism must be managed properly. And how do you manage all your rules in an IS of more than 400 applications with probably more than, let's say 5000 services?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p