{"id":71,"date":"2016-08-30T07:25:52","date_gmt":"2016-08-30T07:25:52","guid":{"rendered":"http:\/\/www.nedlowe.co.uk\/blog\/?p=71"},"modified":"2016-08-30T07:25:52","modified_gmt":"2016-08-30T07:25:52","slug":"class-libraries-with-microservices","status":"publish","type":"post","link":"https:\/\/www.nedlowe.co.uk\/blog\/?p=71","title":{"rendered":"Class Libraries With Microservices"},"content":{"rendered":"

Back in the olden days, everyone went nuts for Service Oriented Architecture. \u00a0Many consultant dollars were made. \u00a0Everyone temporarily forgot who Fred Brooks was\u00a0(No Silver Bullet<\/a>). Time moved on, the hype died down. \u00a0But just like a\u00a0Jeffrey<\/a>\u00a0– IT COMES BACK. \u00a0Yes, I’m talking about micro-services.<\/p>\n

Martin Fowler has a really nice piece on this topic:\u00a0http:\/\/martinfowler.com\/articles\/microservices.html<\/a>\u00a0where he talks about the advantages of being at least familiar with the approach – especially when designing for cloud-based applications.<\/p>\n

With that in mind, having a decentralised, distributed design was important to me as I map out the design for Argomi on the back of\u00a0whatever receipts and envelopes\u00a0I can get my hands on (I look forward to the day when tablets provide me the functionality of pencil and paper). \u00a0However,\u00a0I have now stumbled across a question\u00a0I have previously agonised over: the shared class library.<\/p>\n

If we are splitting up a design into pieces, then it seems obvious to want to have a class library shared amongst all services\u00a0with business logic encapsulated and lots of nice code-reuse. The issue comes from the implicit coupling.<\/p>\n

One of the ‘points’ of microservices is that each service is independent of the others, and can have its own release cycle – or be completely replaced with an improved version, and the other services don’t necessarily need to even know. \u00a0This leads to articles like:\u00a0http:\/\/www.simplicityitself.io\/our%20team\/2015\/01\/12\/sharing-code-between-microservices.html<\/a>\u00a0which suggest not sharing anything – even class libraries – since\u00a0changes may require all services to be upgraded at the same time. It also pretty much forces you to use the same technology for all services so that the class library can be shared.<\/p>\n

My feeling right now is that avoiding a potential coupling is normally not worth the cost of reimplementing complicated business logic and that one should:<\/p>\n