Mixing
How to reuse code in microservices architecture [closed]
I have 2 services (service1 and service2),and both services are using the same data model "studentModel",I'm wondering how to share the studentModel between the two services.
1.Build a studentModel.jar , and all the services refer to this jar
2.Copy & Paste code
Please help me how to reuse code in microservices architecture.
java architecture microservices
asked Jan 2 at 1:51
chenchen
665
closed as primarily opinion-based by Jason, chrylis, david, Ian Lim, Mickael Maison Jan 2 at 11:13
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
add a comment |
I have 2 services (service1 and service2),and both services are using the same data model "studentModel",I'm wondering how to share the studentModel between the two services.
1.Build a studentModel.jar , and all the services refer to this jar
2.Copy & Paste code
Please help me how to reuse code in microservices architecture.
java architecture microservices
asked Jan 2 at 1:51
chenchen
665
closed as primarily opinion-based by Jason, chrylis, david, Ian Lim, Mickael Maison Jan 2 at 11:13
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
build a jar and add it as dependency to your service projects
– Kartik
Jan 2 at 1:55
You have to treat any code dependency like you would treat an external dependency, e.g. an open source component from github. That means you have to version the components correctly and move up versions like you would with an external dependency.
– Oswin Noetzelmann
Jan 2 at 23:44
add a comment |
I have 2 services (service1 and service2),and both services are using the same data model "studentModel",I'm wondering how to share the studentModel between the two services.
1.Build a studentModel.jar , and all the services refer to this jar
2.Copy & Paste code
Please help me how to reuse code in microservices architecture.
java architecture microservices
asked Jan 2 at 1:51
chenchen
665
I have 2 services (service1 and service2),and both services are using the same data model "studentModel",I'm wondering how to share the studentModel between the two services.
1.Build a studentModel.jar , and all the services refer to this jar
2.Copy & Paste code
Please help me how to reuse code in microservices architecture.
java architecture microservices
java architecture microservices
asked Jan 2 at 1:51
chenchen
665
asked Jan 2 at 1:51
chenchen
665
asked Jan 2 at 1:51
chenchen
665
asked Jan 2 at 1:51
chenchen
665
asked Jan 2 at 1:51
chenchen
665
665
closed as primarily opinion-based by Jason, chrylis, david, Ian Lim, Mickael Maison Jan 2 at 11:13
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
closed as primarily opinion-based by Jason, chrylis, david, Ian Lim, Mickael Maison Jan 2 at 11:13
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
build a jar and add it as dependency to your service projects
– Kartik
Jan 2 at 1:55
You have to treat any code dependency like you would treat an external dependency, e.g. an open source component from github. That means you have to version the components correctly and move up versions like you would with an external dependency.
– Oswin Noetzelmann
Jan 2 at 23:44
add a comment |
build a jar and add it as dependency to your service projects
– Kartik
Jan 2 at 1:55
You have to treat any code dependency like you would treat an external dependency, e.g. an open source component from github. That means you have to version the components correctly and move up versions like you would with an external dependency.
– Oswin Noetzelmann
Jan 2 at 23:44
build a jar and add it as dependency to your service projects
– Kartik
Jan 2 at 1:55
build a jar and add it as dependency to your service projects
– Kartik
Jan 2 at 1:55
You have to treat any code dependency like you would treat an external dependency, e.g. an open source component from github. That means you have to version the components correctly and move up versions like you would with an external dependency.
– Oswin Noetzelmann
Jan 2 at 23:44
You have to treat any code dependency like you would treat an external dependency, e.g. an open source component from github. That means you have to version the components correctly and move up versions like you would with an external dependency.
– Oswin Noetzelmann
Jan 2 at 23:44
add a comment |
3 Answers
3
active
oldest
votes
When it comes to microservices, its ok to keep duplicated files because you might end up with a distributed monolith. Remember the Bounded Context from DDD and use your thought process. No shared library means no coupling.
But again the DRY (Don't Repeat Yourself) says you should not have duplicate, but to what extent?
One failure in one Library should not cause all your microservices to fail using that library, then the whole purpose of microservice is of no use.
There are tools to shared code among microservices, you can have a look into https://bitsrc.io/
All these are my thought, there must be some better way.
answered Jan 2 at 2:01
manas dashmanas dash
1127
Yes,Coupling and DRY are not compatible in microservices architecture.
– chen
Jan 2 at 2:08
I think DRY and Decoupling are perfectly compatible. In a Microservice environment each service should have a purpose in the system, so the module might not be a duplication as it can diverge in the future. The reason to use the same jar with the same model is only connected to the fact they have just one reason to change. If they have more, than it's not a duplication.
– Mario Santini
Jan 2 at 7:47
See my comment on the OPs question. Just treat the dependency like an external one with correct versioning. Duplicating files will run you quickly into update hell.
– Oswin Noetzelmann
Jan 2 at 23:46
add a comment |
I would recommend going even further. From my experience, the best approach would be the following:
- to build a separate module with all models for the microservice
- to build a separate client library (module) for the microservice
Following this approach, you can release a new client library each time you change your micro-service - it will be easy to maintain and manage.
In addition, it will help you to save a lot of time when your system grows. Just imagine, you're going to use your core service (e.g. user service or profile service) as a dependency for all other services. Copy-paste is definitely not an option in this case.
answered Jan 2 at 7:39
Arthur GurovArthur Gurov
117410
add a comment |
For better version control, I would recommend you to build a jar and add it as a dependency on your microservices. Alternatively, you can also explore git sub modules by putting duplicate codes in sub modules and utilizing it in your respective microservice module.
answered Jan 2 at 2:15
mkjhmkjh
1,1501023
add a comment |
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
When it comes to microservices, its ok to keep duplicated files because you might end up with a distributed monolith. Remember the Bounded Context from DDD and use your thought process. No shared library means no coupling.
But again the DRY (Don't Repeat Yourself) says you should not have duplicate, but to what extent?
One failure in one Library should not cause all your microservices to fail using that library, then the whole purpose of microservice is of no use.
There are tools to shared code among microservices, you can have a look into https://bitsrc.io/
All these are my thought, there must be some better way.
answered Jan 2 at 2:01
manas dashmanas dash
1127
Yes,Coupling and DRY are not compatible in microservices architecture.
– chen
Jan 2 at 2:08
I think DRY and Decoupling are perfectly compatible. In a Microservice environment each service should have a purpose in the system, so the module might not be a duplication as it can diverge in the future. The reason to use the same jar with the same model is only connected to the fact they have just one reason to change. If they have more, than it's not a duplication.
– Mario Santini
Jan 2 at 7:47
See my comment on the OPs question. Just treat the dependency like an external one with correct versioning. Duplicating files will run you quickly into update hell.
– Oswin Noetzelmann
Jan 2 at 23:46
add a comment |
When it comes to microservices, its ok to keep duplicated files because you might end up with a distributed monolith. Remember the Bounded Context from DDD and use your thought process. No shared library means no coupling.
But again the DRY (Don't Repeat Yourself) says you should not have duplicate, but to what extent?
One failure in one Library should not cause all your microservices to fail using that library, then the whole purpose of microservice is of no use.
There are tools to shared code among microservices, you can have a look into https://bitsrc.io/
All these are my thought, there must be some better way.
answered Jan 2 at 2:01
manas dashmanas dash
1127
Yes,Coupling and DRY are not compatible in microservices architecture.
– chen
Jan 2 at 2:08
I think DRY and Decoupling are perfectly compatible. In a Microservice environment each service should have a purpose in the system, so the module might not be a duplication as it can diverge in the future. The reason to use the same jar with the same model is only connected to the fact they have just one reason to change. If they have more, than it's not a duplication.
– Mario Santini
Jan 2 at 7:47
See my comment on the OPs question. Just treat the dependency like an external one with correct versioning. Duplicating files will run you quickly into update hell.
– Oswin Noetzelmann
Jan 2 at 23:46
add a comment |
When it comes to microservices, its ok to keep duplicated files because you might end up with a distributed monolith. Remember the Bounded Context from DDD and use your thought process. No shared library means no coupling.
But again the DRY (Don't Repeat Yourself) says you should not have duplicate, but to what extent?
One failure in one Library should not cause all your microservices to fail using that library, then the whole purpose of microservice is of no use.
There are tools to shared code among microservices, you can have a look into https://bitsrc.io/
All these are my thought, there must be some better way.
answered Jan 2 at 2:01
manas dashmanas dash
1127
When it comes to microservices, its ok to keep duplicated files because you might end up with a distributed monolith. Remember the Bounded Context from DDD and use your thought process. No shared library means no coupling.
But again the DRY (Don't Repeat Yourself) says you should not have duplicate, but to what extent?
One failure in one Library should not cause all your microservices to fail using that library, then the whole purpose of microservice is of no use.
There are tools to shared code among microservices, you can have a look into https://bitsrc.io/
All these are my thought, there must be some better way.
answered Jan 2 at 2:01
manas dashmanas dash
1127
answered Jan 2 at 2:01
manas dashmanas dash
1127
answered Jan 2 at 2:01
manas dashmanas dash
1127
answered Jan 2 at 2:01
manas dashmanas dash
1127
1127
Yes,Coupling and DRY are not compatible in microservices architecture.
– chen
Jan 2 at 2:08
I think DRY and Decoupling are perfectly compatible. In a Microservice environment each service should have a purpose in the system, so the module might not be a duplication as it can diverge in the future. The reason to use the same jar with the same model is only connected to the fact they have just one reason to change. If they have more, than it's not a duplication.
– Mario Santini
Jan 2 at 7:47
See my comment on the OPs question. Just treat the dependency like an external one with correct versioning. Duplicating files will run you quickly into update hell.
– Oswin Noetzelmann
Jan 2 at 23:46
add a comment |
Yes,Coupling and DRY are not compatible in microservices architecture.
– chen
Jan 2 at 2:08
I think DRY and Decoupling are perfectly compatible. In a Microservice environment each service should have a purpose in the system, so the module might not be a duplication as it can diverge in the future. The reason to use the same jar with the same model is only connected to the fact they have just one reason to change. If they have more, than it's not a duplication.
– Mario Santini
Jan 2 at 7:47
See my comment on the OPs question. Just treat the dependency like an external one with correct versioning. Duplicating files will run you quickly into update hell.
– Oswin Noetzelmann
Jan 2 at 23:46
Yes,Coupling and DRY are not compatible in microservices architecture.
– chen
Jan 2 at 2:08
Yes,Coupling and DRY are not compatible in microservices architecture.
– chen
Jan 2 at 2:08
I think DRY and Decoupling are perfectly compatible. In a Microservice environment each service should have a purpose in the system, so the module might not be a duplication as it can diverge in the future. The reason to use the same jar with the same model is only connected to the fact they have just one reason to change. If they have more, than it's not a duplication.
– Mario Santini
Jan 2 at 7:47
I think DRY and Decoupling are perfectly compatible. In a Microservice environment each service should have a purpose in the system, so the module might not be a duplication as it can diverge in the future. The reason to use the same jar with the same model is only connected to the fact they have just one reason to change. If they have more, than it's not a duplication.
– Mario Santini
Jan 2 at 7:47
See my comment on the OPs question. Just treat the dependency like an external one with correct versioning. Duplicating files will run you quickly into update hell.
– Oswin Noetzelmann
Jan 2 at 23:46
See my comment on the OPs question. Just treat the dependency like an external one with correct versioning. Duplicating files will run you quickly into update hell.
– Oswin Noetzelmann
Jan 2 at 23:46
add a comment |
I would recommend going even further. From my experience, the best approach would be the following:
- to build a separate module with all models for the microservice
- to build a separate client library (module) for the microservice
Following this approach, you can release a new client library each time you change your micro-service - it will be easy to maintain and manage.
In addition, it will help you to save a lot of time when your system grows. Just imagine, you're going to use your core service (e.g. user service or profile service) as a dependency for all other services. Copy-paste is definitely not an option in this case.
answered Jan 2 at 7:39
Arthur GurovArthur Gurov
117410
add a comment |
I would recommend going even further. From my experience, the best approach would be the following:
- to build a separate module with all models for the microservice
- to build a separate client library (module) for the microservice
Following this approach, you can release a new client library each time you change your micro-service - it will be easy to maintain and manage.
In addition, it will help you to save a lot of time when your system grows. Just imagine, you're going to use your core service (e.g. user service or profile service) as a dependency for all other services. Copy-paste is definitely not an option in this case.
answered Jan 2 at 7:39
Arthur GurovArthur Gurov
117410
add a comment |
I would recommend going even further. From my experience, the best approach would be the following:
- to build a separate module with all models for the microservice
- to build a separate client library (module) for the microservice
Following this approach, you can release a new client library each time you change your micro-service - it will be easy to maintain and manage.
In addition, it will help you to save a lot of time when your system grows. Just imagine, you're going to use your core service (e.g. user service or profile service) as a dependency for all other services. Copy-paste is definitely not an option in this case.
answered Jan 2 at 7:39
Arthur GurovArthur Gurov
117410
I would recommend going even further. From my experience, the best approach would be the following:
- to build a separate module with all models for the microservice
- to build a separate client library (module) for the microservice
Following this approach, you can release a new client library each time you change your micro-service - it will be easy to maintain and manage.
In addition, it will help you to save a lot of time when your system grows. Just imagine, you're going to use your core service (e.g. user service or profile service) as a dependency for all other services. Copy-paste is definitely not an option in this case.
answered Jan 2 at 7:39
Arthur GurovArthur Gurov
117410
answered Jan 2 at 7:39
Arthur GurovArthur Gurov
117410
answered Jan 2 at 7:39
Arthur GurovArthur Gurov
117410
answered Jan 2 at 7:39
Arthur GurovArthur Gurov
117410
117410
add a comment |
add a comment |
For better version control, I would recommend you to build a jar and add it as a dependency on your microservices. Alternatively, you can also explore git sub modules by putting duplicate codes in sub modules and utilizing it in your respective microservice module.
answered Jan 2 at 2:15
mkjhmkjh
1,1501023
add a comment |
For better version control, I would recommend you to build a jar and add it as a dependency on your microservices. Alternatively, you can also explore git sub modules by putting duplicate codes in sub modules and utilizing it in your respective microservice module.
answered Jan 2 at 2:15
mkjhmkjh
1,1501023
add a comment |
For better version control, I would recommend you to build a jar and add it as a dependency on your microservices. Alternatively, you can also explore git sub modules by putting duplicate codes in sub modules and utilizing it in your respective microservice module.
answered Jan 2 at 2:15
mkjhmkjh
1,1501023
For better version control, I would recommend you to build a jar and add it as a dependency on your microservices. Alternatively, you can also explore git sub modules by putting duplicate codes in sub modules and utilizing it in your respective microservice module.
answered Jan 2 at 2:15
mkjhmkjh
1,1501023
edited Jan 2 at 2:24
answered Jan 2 at 2:15
mkjhmkjh
1,1501023
answered Jan 2 at 2:15
mkjhmkjh
1,1501023
answered Jan 2 at 2:15
mkjhmkjh
1,1501023
1,1501023
add a comment |
add a comment |
build a jar and add it as dependency to your service projects
– Kartik
Jan 2 at 1:55
You have to treat any code dependency like you would treat an external dependency, e.g. an open source component from github. That means you have to version the components correctly and move up versions like you would with an external dependency.
– Oswin Noetzelmann
Jan 2 at 23:44