Sharing code between services requires careful thought and planning to avoid too much coupling between service impls. I have seen both extremes - no sharing and uber sharing (i.e., too much).
So my advice is do share code just don’t overdo it.
Some modules that I found useful (in hindsight) to share by user interfaces and various services are:
- schema (code that validates XML against schema)
- persistence (consistent way of accessing database)
- msgmapper (mapping XML to POJOs that you pass into business logic)
- domainmodel (the most important package/module that most apps don't have)
2 comments:
I definitely experienced both extremes of this. Finding that balance as you pointed out is the key. Most of the time the lessons have come the hard way for me. It's also one of the potential dangers of a SOA approach to development. If not properly done then those wonderfully reusable services can cause bad things to reasonably good people.
The same arguments apply to shared data usage. It is a mistake to use SOA to store data at one location (at the source) and to get to that data by service calls. In this way you build in functional coupling and you get into trouble when the organisation splits up into autonomous departments or companies.
Better is to accept redundant datastores and use services to synchronise. It's better performance of the datahandling (like caching), no single points of failure, and the business is much more flexibel. Of course you need semantic harmonization (canonical data model), but that is also the case when using just one datasource.
Post a Comment