In the first episode of our Money Dashboard Developer Series, Adam Lubek dissects Udi Dahan's 'Business Logic, a different perspective'.
Presenting Udi Dahan's business logic
, we like to learn new things and expand our horizons. One way we tend to do this is through group learning sessions where we watch development related lectures or talks from conferences.
The latest video we watched was
. This video encouraged us to take a step back and take on a fresh perspective regarding software reuse and how it sometimes can cause problems.
While we agreed that indeed, Udi is right about how software reuse can sometimes be problematic, he didn't unfortunately suggest solutions that our development team would be happy with.
An example problem was business requirement to have string up to X characters (which usually tend to be duplicated throughout solution layers for various reasons) and how to handle inevitable change to that requirement.
Udi suggested that it's OK to duplicate logic instead of coming up with reuse strategies and when requirement to change the rule comes, just use source control to check where to apply changes so no place is missed (as theoretically we would have all changes under one issue).
We discussed that later and agreed that this is not viable solution as it's sometimes hard to track initial issue. Or how about if developer forgot to reference one of the commits properly?
Another problem are cases where rule was added somewhere else later on under another issue.
P is for problematic reuse
Regardless of our disagreement with suggested solution, we agreed that reuse can be problematic (for example: how do you efficiently share logic across layers and different platforms/programming languages?) and actually, we have an example of how reuse is causing us some problems currently.
We have business logic layer which is shared by various services that are used by number of platforms we have. This means that any change to business logic for a specific platform requires deployment of all of the services that use business logic layer (as keeping service out of sync is never a good idea).
We agreed that we need to come up with a better solution for this, with initial ideas being separate business logic which would certainly result in some duplications (no!!) or come up with better deployment strategies.
This looks likely to be a topic of team discussions over upcoming weeks; which we'll commit to because we strive to adhere to one of the most fundamental principles of software development. Can't live with it, can't live without it.
In general, talk was interesting and thanks to Udi for prompting us to think about fundamental development practices that like anything, can have exceptions.
Maybe sometimes, when supported by strong case, fundamental practice isn't right for the solution?
About the author
Adam Lubek is a Developer here at Money Dashboard and spends his time TDDing and complaining about missing automated tests. He enjoys listening to Hope Conspiracy while at work. If you have a question on what Adam has blogged about, do
with our #askAdam hashtag.