Mark is a graph advocate and field engineer for Neo Technology, the company behind the Neo4j graph database. As a field engineer, Mark helps customers embrace graph data and Neo4j building sophisticated solutions to challenging data problems. When he's not with customers Mark is a developer on Neo4j and writes his experiences of being a graphista on a popular blog at http://markhneedham.com/blog. He tweets at @markhneedham. Mark is a DZone MVB and is not an employee of DZone and has posted 553 posts at DZone. You can read more from them at their website. View Full User Profile

Coding: Shared Libraries

02.27.2010
| 4818 views |
  • submit to reddit

On a few projects that I've worked on one of the things that we've done is create a shared library of objects which can be used across several different projects and while at the time it seemed like a good idea, in hindsight I'm not sure if it's an entirely successful strategy.

I'm quite a fan of not recreating effort which is generally the goal when trying to pull out common code and within one team this seems to be a good approach the majority of the time.

When it comes to sharing across teams then I think we need to consider the perceived benefits a bit more because it doesn't come without costs.

These are some of the types of code that we've shared previously:

Domain objects

I think this is the most dangerous type of code to share because although we often do have the same domain concepts in different projects, it's quite rare that they mean exactly the same thing.

In addition there is an implicit coupling created with our database since we pretty much now have to make sure that our database schema matches up with the current version of that domain object.

Either that or we do have a shared database for all the applications which use that shared domain object in which case we have an even stronger coupling between applications.

We're assuming that the two application have exactly the same domain concept and from my experience quite often that isn't the case – even if there is a concept with the same name it may be used in different ways or mean something completely different in different applications.

This is quite similar to the problem with having a universal domain model which Dan points out in his classic SOA article.

In general I don't think it makes sense to share this type of code.

Test code

This one seems like it should fairly universally a good idea – after all we often import 3rd party testing libraries so it seems like just sharing some common testing code shouldn't be much different.

One piece of code that we shared was the Selenium bootstrapping code and this approach worked reasonably well until we wanted to adjust the amount of time between each command because commands were being sent to the browser before elements had the chance to load.

Apart from the fact that the other users of the library didn't want anything change with respect to how they used the code we had to go and make the change in another project, build that and then update the reference that we had to the library.

Certainly this process would have been made easier if we'd used something like Ivy but the amount of duplication of code that we were saving didn't seem worth the hassle it caused so we ended up inlining the code.

Infrastructure code

General infrastructure code e.g. code to handle NHibernate transactions which is quite unlikely to change seems one candidate which can work quite well in a shared library and so far I haven't seen many problems arise from doing this.

I think the key with these bits of reusable code is that we keep them quite small and ensure that they have only one responsibility which will be useful for all the applications.

We eventually ended up slimming down our shared library and the majority of the code that remains in there is solving specific infrastructure type problems which will be the same across any applications using the same technical stack.

Things to be careful about when sharing code

One reason that we may share code is so that if there is a change then it only needs to be done in one place.

We need to have a degree of confident that if we put code in a shared library that this is actually the case.

If it's likely that different applications might need shared code to change in different ways then we might not want to make that bit of code shared otherwise we'll just end up with application specific code in a shared library.

From what I've noticed it makes most sense to put code which is unlikely to change and is generic enough to be useful across several applications as is into shared libraries.

For any other code it might actually be beneficial to accept that there will be some duplication between applications in the same organisation and not try and pull out a common piece.

From http://www.markhneedham.com/blog

Published at DZone with permission of Mark Needham, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Johannes Brodwall replied on Sat, 2010/02/27 - 6:51am

Good points. I think that when we try to reuse test code or infrastructure code we forget to ask the question: "If this code is smart to reuse, why don't Selenium or NHibernate include it in the first place?"

Alessandro Santini replied on Mon, 2010/03/01 - 5:30am

Mark,

Hopefully I will not mind if, once again, I partly disagree with your and Dan North's (whoever he is) reasoning.

My concerns are mostly about your view on sharing domain objects. The sentence "although we often do have the same domain concepts in different projects, it's quite rare that they mean exactly the same thing" sounds too wrong to be true: I do not know what industries you are consulting but, to make an example, a "statement of account" is a statement of account for any bank of the world, a "clinical record" is a clinical record for any hospital in the world, an "insurance claim" is a claim for any insurance company in the world. There is no ambiguity there. If you were not a mother tongue, I would assume you meant something else here.

I accept that there might be local differences introduced by technical, cultural or regulatory aspects; this means that the contents of a business concept might contain more or less information, but still will share a core which is common to all the players in a particular business industry.

As a proof of my statement (and due counter-proof to Dan North's statement) I do not want to point at the obvious, but there exist universal messaging standards like ISO20022 (Universal financial industry message scheme) and HL7 (standards for interoperability of health information technology) and, to give broader context to my statement, EDIFACT (United Nations Directories for Electronic Data Interchange for Administration, Commerce and Transport) which are adopted in tens of countries in the world. If the business concepts would be that different, I really fail to see how standard messages could be adopted.

I also take a chance to comment on Dan North's sentence "The mistake that enterprise information architects (or people with similarly named roles) make is trying to define what the business concept means to each of the people using it." - I believe this is where your original sentence came from. I do not believe we share the same understanding of this sentence.

My understanding of that sentence is that an Information Architect, rather than imposing its own definition of a business concept, should distill a common definition by harvesting the different views that different stakeholders have on that business concept.

This does not mean that a business concept has different meanings for different people: it simply means that different stakeholders, for example different organizational units within the same company, look at a specific facet of a business concept often ignoring the other facets. The goal of an information architect is to harvest all these facets and gather them into one or more border-context entities.

So, to conclude, there are different views on the same business concepts. This does not mean that business objects should not been reused; it rather means that different views and meanings shall be gathered and addressed in order to produce reusable, extensible models.

Ronald Miura replied on Mon, 2010/03/01 - 10:05am in response to: Alessandro Santini

I wouldn't say that business objects should never be reused, but I wonder if reuse should be the norm or an (very well-thought) exception.

High-level concepts are the same, a 'person' is still a 'person' in accounting, payment, or sales. But as you said, each system views it in very different ways.

Standard protocols and formats are necessary, but they (well, t) always model just a little subset of the concepts, the bare minimum required for the systems to be able to talk to each other. The internal representation of them are always much more complex and specific to the system. To reuse these implementations, one would have either a too-complex or too-limited API to work with, most of the time.

If you are talking not about reusing code or libraries, but 'services' (whatever it means :)), it will fit in the 'standard protocol' case, not in 'shared libraries', which is what the article author is talking about, anyway.

And reuse IS overrated.

Alessandro Santini replied on Mon, 2010/03/01 - 10:25am in response to: Ronald Miura

Ronald,

I did not say that each system sees it in different ways - I said that each stakeholder of a system sees a facet (or a portion) of a business entity (which has nothing to do with a service). I am sure you will agree this is very different.

The author is indeed talking about shared libraries of business objects; the protocol I mentioned are all made up of messages that in turn are made up of business entities.

"And reuse IS overrated". A sentence like this, without any context or explaination, should not be here.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.