There's compile-time DRY, and then there's run-time DRY.
* Compile-time DRY allows me to change my code quickly and reliably.
* Run-time DRY allows me to deploy services independently.
Sometimes these objectives are at odds. Sharing code among my services, can make my code less repetitive at compile time, but it can also lead to duplicated execution at run time. And vice versa.
The important thing (besides reading the latest blogs and following the latest tech trends, of course) is to figure out what your objective is.
For example, at my company, we want (1) to improve the ease of code development, and (2) to increase production stability for critical functionality.
So we have microservices that allow us to prevent non-critical issues from taking out critical functions. And we use extensive share code for HTTP, JSON, templating, logging, some business logic etc. in order to make development easier. We don't care about decoupling releases or segmenting production ownership. In other words, run time DRY isn't important to us. Our services are simply ways to intelligently distribute execution across limited resources.
Assess your objectives, and then choose the most solution that will meet them. Never do the reverse.
If you need separation of concerns and information hiding at runtime, this article has some good tips.
* Compile-time DRY allows me to change my code quickly and reliably.
* Run-time DRY allows me to deploy services independently.
Sometimes these objectives are at odds. Sharing code among my services, can make my code less repetitive at compile time, but it can also lead to duplicated execution at run time. And vice versa.
The important thing (besides reading the latest blogs and following the latest tech trends, of course) is to figure out what your objective is.
For example, at my company, we want (1) to improve the ease of code development, and (2) to increase production stability for critical functionality.
So we have microservices that allow us to prevent non-critical issues from taking out critical functions. And we use extensive share code for HTTP, JSON, templating, logging, some business logic etc. in order to make development easier. We don't care about decoupling releases or segmenting production ownership. In other words, run time DRY isn't important to us. Our services are simply ways to intelligently distribute execution across limited resources.
Assess your objectives, and then choose the most solution that will meet them. Never do the reverse.
If you need separation of concerns and information hiding at runtime, this article has some good tips.