Common code used by all Microservices

I have an architectural question -

We have one microservice for say, four different domain objects (each is an aggregate root). Now, there could be some common code (for example the domain objects themselves, or some common data access code) among them - so my question is where to keep such common code?

For now, we’ve created a common project in sbt, which the other microservices are referring to.

  1. Is this an anti-pattern?
  2. Where should the common code be kept?
  3. If I write some common code (which includes Cassandra related code) is it problematic to use lagomScaladslPersistenceCassandra as a dependency in the common sbt project?
1 Like
  1. domain objects belong to the domain so this should not be shared. So in this case it is a anti pattern.

Generally, domain non specific things can be shared. Like helper functions or objects.

For this case we create “util*” sbt projects that are constructed like api projects and are referenced as dependencies by impl projects. We have mutliple “util” projects depending on the needed functionality.

  1. we are using “multiple builds” and store api* and util* builds on local Artifactory.

Api* and util* builds are then referenced in impl projects as any other dependency.

  1. it is not problematic if your util project use the same Lagom version as implementations projects referencing them. This is also one of the main reasons why we have multiple util projects because some of them do not require special dependencies.
1 Like

Hi Manoj,

It’s always good to follow DDD Domain Driven Design. As we know DDD is a modeling technique which defines the bounded context.
In my opinion, creating commonly shared domain objects creates lots of problems.
Having a common aggregate root domain seems to be a good idea in the first place but believe me, this might be the thing which is complex and very hard to maintain for a long time.
So I will suggest instead of creating a common domain root class across the entire application you should consider creating classes in a bounded context.
We should honor DDD while following microservice architecture!!! And this is why Lagom fits the best.

Now there might be some modules which can be used by other api or impl modules like common validators, common exception handler.
Which I guess you can include inside a common module and have its dependency inside other modules.
And I don’t think that’s an anti-pattern.

@Guys please let me know if I miss something or if I am wrong.