We have one microservice that will be deployed on two different environments(A and B). There are some common fields and also some are specific to the environment.


SomeEntity for environment A have only name and age and their validation.

SomeEntity for environment B have only dept and experience and their validation.

There are some fields that are common in both the environments.

We don't want to create two different Entities for both the environment because there are only 2-3 fields that are specific to the environment and 23-25 fields are common.

Actually, we are looking for some design pattern or tool which handle this situation the in the best way OR any inbuilt feature in Hibernate or Spring framework.

Can someone guide what could be the best way to handle this situation?

  • What is the difference between the environments? (Conceptually) – marstato Aug 8 '18 at 7:02
  • Actually, one MS will be used by two different clients, in that case, there are some different fields for the same entity as I mentioned in Question. – Mehraj Malik Aug 8 '18 at 7:09
  • Basically, the rows in the database will have informed one or another field (age or dept) based on the environment where they were created. So, why to care about dynamic or conditional mappings? Just load the whole entity and let the business rules to work according to the environment – Laiv Aug 8 '18 at 7:18
  • When a user makes a POST request we have to validate the fields. So, in that case, we will not be able to find out for which for env the req is coming and we form validations will fail. If the req was for A but we will still validate the dept and experience fields. – Mehraj Malik Aug 8 '18 at 7:28
  • 1
    Basically, you want multitenancy from a system that was not designed to be it. Don't expect frameworks and tools to resolve design decisions. If you find yourself screwing your code and the framework implementation, take it as a warning. It's a design flaw. – Laiv Aug 8 '18 at 8:17

Having branches in your code that are enabled per customer is not a practical solution. 20 customers with special demands later and your codebase is a pile of excrement.

So I'll recommend you use feature flags. A feature flag is some sort of boolean configuration property. Those flags should ideally be stored in a place that does not require a developer to change them (e.g. functional configuration, as opposed to technical configuration).

Use one for each of the optional fields:

  • name
  • age
  • departement
  • experience

(Named something like employeeNamesEnabled)

On the one environment, turn the name and age flags on. On the other, the departement and exprience flags. All code that needs to deal with these needs to branch on the flags.

Also, it seems your team/company is not aware of the full effect this will have. Think about what consequences these additional fields have for other business logic. Define the desired behaviour of the application for different flag configurations in the areas that touch these fields before doing any coding.

Also, you need to seriously think about what special requests you want to support for only some customers exclusively. With this approach, too, if you have 20 "versions" of your application for 20 different customers working with the codebase will be a nightmare at best.

Another alternative is to allow your customers/tenants to define arbitrary fields for every entity. Your application would only validate and store those but not do any processing on them. Pro: customers can help themselves, not even a phone call to your company is needed. Con: no business logic on custom fields.

  • I totally agree, it more Design or Architecture that tools or framework. However, we're thinking that if we can eliminate if..else.. statements. – Mehraj Malik Aug 8 '18 at 8:53
  • @MehrajMalik i dont see how that would be possible. You can avoid those if you really just store them. But even a @ConditionalOnProperty annotation is an if-else in disguise – marstato Aug 8 '18 at 8:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.