Building micro services through Event Driven Architecture part20 : Shared Libraries

Building micro services through Event Driven Architecture part20 : Shared Libraries

This tutorial is the 20th part of a series : Building microservices through Event Driven Architecture.

The previous step is about Building micro services through Event Driven Architecture part19 : Building and Securing Real Time Communications using SignalR and Azure Active

A microservice architecture  structures an application as a set of loosely coupled services.

An real advantage is that when there is a critical need to update a resource, only the microservice containing this resource will be updated, the other microservices  remaining compatible with the modification, unlike the entire  application in a classic architecture.

But what about shared code ?

Because I do not want to code the same functionality several times , I can follow the DRY principle ( Don’t Repeat Yourself)  :  “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system”

But when following DDD (Domain Driven Design) , The DRY principle is about domain knowledge and code duplication may be perfectly fine. 

For those unfamiliar with DDD (Domain Driven Design), I recommend learning the basics.

In this tutorial, I will not discuss about the pros and cons of code sharing between micro services, but I will show to share code efficiently between microservices when needed.  I will not share business functionnalites between microservices but only technical libraries like logging/monitoring, helpers, tools, etc…

I will use the versioning package following the semver principle
This way, when code common to the microservice is updated, the version must be incremented and the package published in a nuget server.
So microservices can use the new version of the package only when needed and independently.

Packaging and Versionning 

To package a Library, I have to open the project properties and check GeneratePackageOnBuild, and fill the properties accordingly as shown in the following figure :

I can also edit the LogCorner.EduSync.Speech.SharedKernel.csproj

    <Title>The Speech Micro Service Command Shared Kernel</Title>
    <Company>Gora LEYE</Company>
    <Description>The Speech Micro Service Command Shared kernel contains a set of tools to serialize and deserialize events</Description>
    <PackageTags>cqrs;event driven;serialization;</PackageTags>
    <PackageReleaseNotes>update package metadata</PackageReleaseNotes>

So every time, the project is build , a package should be generated, Now I have to pubish the package in the next step

Publish Packages 

To pubish the package to github, I have to create an account and create an API Key as following

Because I will publish the package during the build process, I must create a service connection in azure devops ( ) and fill the FeedUrl and AoiKey accordingly.

The steps to create an azure devops pipemine are discussed here

Here is the final build configuration file

  - repository: self
    type: git
    ref: develop
- job: Job_1
  displayName: Agent job 1
  - checkout: self
  - task: DotNetCoreCLI@2
    displayName: dotnet restore
      command: restore
      projects: '**/*.csproj'
  - task: DotNetCoreCLI@2
    displayName: dotnet build
      projects: '**/*.csproj'
  - task: VSBuild@1
    displayName: database build
      solution: '**\*.sqlproj'
  - task: DotNetCoreCLI@2
    displayName: dotnet test
      command: test
      projects: '**/*Unit[Tt]ests/*.csproj'
  - task: DotNetCoreCLI@2
    displayName: dotnet pack
      command: 'pack'
      packagesToPack: 'src/LogCorner.EduSync.Speech.SharedKernel/LogCorner.EduSync.Speech.SharedKernel.csproj'
      packDirectory: '$(Build.ArtifactStagingDirectory)/Nugets'
      nobuild: true
      versioningScheme: 'off'
  - task: NuGetCommand@2
    displayName: NuGet push
      command: 'push'
      packagesToPush: '$(Build.ArtifactStagingDirectory)/Nugets/*.nupkg'
      nuGetFeedType: 'external'
      publishFeedCredentials: ''
      allowPackageConflicts: true
    continueOnError: true

When I update a shared library and push the code to the github repository , azure devops will trigger a build, pack and publish the package to . As a result, a new version of the package is publicly available for demos but it should be private in a production scenario.

Code source is available here : 

Thanks for reading, if you have any feedback, feel free to post it


I'm a microsoft most valuable professional (MVP) .NET Architect and Technical Expert skills located in Paris (FRANCE). The purpose of this blog is mainly to post general .NET tips and tricks, Gora LEYE

Support us

BMC logoBuy me a coffee