When I was building my backend API I used Django combined with django-rest-framework (DRF) because it was the easiest and fastest way to create what I needed.

And I haven't thought about an architecture of it.

And if I understand correctly DRF provides some kind of Model-ViewSet-Serializer pattern.

So my question is: Is making decision what architecture would look like based on framework being used wrong?

  • As per your question in the question itself, rather than the title, no. A framework itself usually provides a standard as to how you should go along building an app with it and is usually pretty opinionated. Most frameworks follow a pattern (i.e. MVC) which you can't (rather shouldn't) stray away from for sanity's sake. Another thing to be aware of is lock-in if a big company is behind a framework. I have a feeling this question is too broad as the term "framework" might be too broad itself nowadays. May 3, 2019 at 20:28

2 Answers 2


Your framework choices strongly influence the architecture your applications will have. Many of the architectural decisions have already been made by the framework for you, so trying to impose your own architecture over that would be like swimming against the current.

But this is kind of the whole point of choosing a framework. Developing a suitable architecture for your application can be tedious when you have to design and build the whole thing yourself.

In practice, unless I'm writing my own framework, I don't like to think all that much about the architecture. Architecture should be something that's just a part of the fabric of your application, not an end in its own right, and if you use a framework that you like that does all of the architectural heavy-lifting for you, so much the better. It means that you spend more time developing actual functionality and less time putting in plumbing.

If you're going to go this route, you have to think carefully about your framework choices and how each one fulfills its role of helping you build your application. But choosing a framework because it is a "quick and dirty" way to get an application working is a perfectly valid choice. It all depends on what your actual needs are.


The answer to your question from the title depends on the definition of "software architecture". One popular definition is: the design decisions which are costly to change at a later point time (at least not without a complete rewrite). So choosing a framework like DRF is an architectural decision.

However, from your question text, I guess you have a much narrower idea of "architecture" in mind, like which layers your program should have, which responsibilities those layers should have, and maybe which technologies are available for each layer. That is the part of a system's architecture for which Robert Harvers answer applies. Here it depends heavily on the specific framework how much freedom it gives you in defining your own layers, and how much it predefines for you.

If it is good or bad to rely on such predefined layer decisions depends mainly on the amount of evolvability you will need for your system. If you expect future requirements which may easily hit the architectural limits of the framework, then the choice was probably a poor one. If you think such requirements are unlikely to arrive over the lifetime of your program, then the choice is fine.

Often, this leads to a dilemma: one picks an "rapid-application-development" framework "to get things done as quickly as possible" (since time-to-market is more important than anything else at the beginning). Later, new requirements show up and cannot be easily integrated into the system because of the framework's limitations. Then it is probably a good idea to throw away the initial version, pick a less limited framework, which may (or may not) include a different programming language, and reimplement the system again from scratch. But when you are in such a situation, better do not to wait too long, otherwise a rewrite becomes too costly and you will be stuck on the initial architecture.

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.