The main issue

Seeing the good support most modern programming platforms have for package management (think gem, npm, pip, etc), does it make sense to design an application or system be composed of internally developed packages, so as to promote and create a loosely coupled architecture?


An example of this would be to create packages for database access, as well as for authentication and other components of the system. These, of course, use external packages as well. Then, your system imports and uses these packages - instead of including their code within its own code base.


To me, it seems that this would promote code decoupling and help maintainability, almost in a Web-based-vs.-desktop-application kind of way (updates are applied almost automatically, single code base for single functionality, etc.).

Does this seem like a rational and sane design concept? Is this actually used as a standard way of structuring applications today?

2 Answers 2


I've been involved in projects like this twice now (both using nuget with .NET), and I would say that on balance it is a good idea. But your mileage may vary.

Don't think for a minute that it's a panacea, that it's going to solve all of your problems without causing new ones. Release management will gain a whole new layer of complexity, you'll need to deal with version-dependency issues you never knew existed, and you will have times when you curse the decision because you've got to upgrade four different packages because of a small bug that you need to fix and release quickly.

On the other hand, you're right that it decouples things nicely. Unless you overdo it, you'll probably find more occasions when you think "oh, that worked out nicely," than "that added a lot of effort." If you have code shared among multiple applications, it's particularly effective because you can easily upgrade your apps independently.

And, if you're anything like me, you'll quickly start writing test apps that use your packages, to remove entire layers of application from your bug-finding process. And that, in itself, can be more than worth the costs.

  • Wonderful input. In general, all things should be balanced, and I like how your comment stays on those lines. It is great to hear that you think it tends to work well in more cases than not... and the appearance of problems is a constant anyway. I love your tip about testing apps :). +1. Commented May 27, 2014 at 20:36
  • 1
    I'd add there are a lot of projects that do this in the *nix world too. You often have libraries separated from front-ends from gui's from development resources, etc. Commented May 28, 2014 at 5:50
  • Interesting. It does sound like nice way to organize a complex system, but I was afraid of it being a case of over-engineering. It looks like if applied with caution, it should not be. Thanks! Commented May 28, 2014 at 17:47

This is a good idea, all in all. You will need to think about setting up an internal package repository (usually called "artifact repository" in the Java world, or "pypi server" in the Python world), so that you keep there those packages you don't want or can't release as open source.

As @pdr has noted, be prepared to have your own dependency hell, where a change to some package requires first another change in another package, and this means not just changing a line of code, but testing it, possibly getting the changes accepted, building a release, and uploading the release to the aforementioned package repository. And then changing what you intended to change.

The only recipe I can give you from my experience to try and minimize this: do not rely solely on abstracting common concepts from your packages into a "common" or "framework" package. This can seem like a very objective thing to do, but it will lead to a monster package that needs frequent, possibly contradictory changes and releases. Much better, think about the functionalities in your system, and create a helper package for each one of them, as you have outlined in your question.

Aside from that, the main benefit you will get is that your apps are insulated from (many) dependencies, so you can exchange them without pain.

  • Excellent tip. I did not consider a common package as an option, but, as you say, I could see it becoming a "reasonable" decision in the future. My intent was more along the lines of components instead of code - so ideally you should not have too many pieces of code that do the same thing in different packages because they are meant to do different things. I would guess that if there are commonalities between packages, that sort of repetition would not violate good programming principles, since the projects are by definition separate. Commented May 28, 2014 at 17:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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