37

When developing a system or application that you plan to use with a certain framework, is it best practice to design the system without the framework in mind, or is it better to design the system with the mindset "well the framework would have an easier time with this".

Robert Pounder
  • 423
  • 4
    What kind of framework are you talking about? Do you mean some niche business-specific framework which is designed to solve very domain-specific problems for a particular industry? (e.g. medical, nuclear, defence, aviation, etc.). Or are you talking about general-purpose frameworks designed to solve technical problems? – Ben Cottrell Apr 12 '17 at 10:10
  • 1
    general-purpose frameworks designed to solve technical problems – Robert Pounder Apr 12 '17 at 10:19
  • Can you give an example of a system design that would be altered based on the choice of a framework? – JeffO Apr 12 '17 at 12:58
  • 2
    Small scale for lack of time (I am in work, may elaborate later): I'm writing a system that generates emails based of designs. - If I were writing this in Laravel I would probably go about using their templating engine "blade" for designing the emails, which would make the designing of the system a lot simpler in terms of flow. However I would have to go about writing a templating engine if I was doing it vanilla PHP, or finding another suitable alternative templating system. It would add to the design process, which the question is referring too. – Robert Pounder Apr 12 '17 at 14:29
  • 3
    This question is going to generate a bunch of vastly different answers because both "framework" and "design" are words overloaded with multiple meanings in our industry. Furthermore, even for a single definition of framework as "general-purpose frameworks designed to solve technical problems", it's going to depend on the specific framework - some frameworks are more opinionated than others. – stannius Apr 12 '17 at 15:19
  • I think you can gain some knowledge if you read about Views in Software Architecture: https://en.wikipedia.org/wiki/4%2B1_architectural_view_model – Ricardo Vigatti Apr 18 '17 at 21:50
  • @RicardoVigatti cool read, but unless your implying that a framework would be considered in the "Development view" I don't really see the relevance since you've given no context. – Robert Pounder Apr 19 '17 at 08:23
  • Is something like that. You should mention the framework and maybe explain the reasons why your team decides to it -respecting the view's audience- but you don't need to explain framework specific details. Answering: Yes, you should consider the framework. – Ricardo Vigatti Apr 19 '17 at 22:42
  • I'd have to disagree after this debate, it seems the "correct" (and heavily agreed upon) way is too design the system, then decide on the framework after; that suits it most, with no consideration for it. – Robert Pounder Apr 20 '17 at 09:36
  • 1
    It would be too bad to be hit by a bus while lost in thought trying to design a wheeled public transit vehicle. –  Jun 02 '17 at 18:02
  • @nocomprende sorry for necro, but I was going through this thread for reference and really liked that analogy +1 :) – Robert Pounder Oct 12 '17 at 10:15
  • I think the answers miss the on-prem use case that you may have to cater the design to the internal framework – lennon310 Nov 21 '20 at 06:05

3 Answers3

51

Your design should meet the clients needs as closely as they can. Remember that design includes little things like:

  • User experience
  • Functionality
  • How pieces of your application communicate (either with itself or external entities)

None of these things should be dictated by the framework. If it's clear that you will be fighting your framework to accomplish these goals, then you choose a new framework that will help you accomplish those goals before you start writing code.

Once you've chosen an appropriate toolset (the framework is a tool), then I recommend using the tools the way they are designed to be used. The further you deviate from the framework design the more you increase the learning curve for your team, and the greater chance of something going wrong.

In Short

  • Design for your users
  • Pick the appropriate tools to accomplish your design
  • Use your tools the way they are designed to be used

Further Thoughts:

After 20+ years of software engineering, and using several frameworks, I've learned a couple lessons. All frameworks are a double edged sword: they both constrain and enable. The issue with deciding your framework before you look at the big 3 I mentioned above is that you might be compromising a good user experience for a mediocre (at best) one. Or you might be forced to deviate from the frameworks design to accomplish some specific functionality.

Berin Loritsch
  • 46,104
  • Would your opinion change based on languages, for example consider the client has requested a ruby project as their in-house developer only knows ruby. Would I not at all be influenced by ruby on rails when designing the system? At what point do you draw a line? I know this is very specific but it's a surprisingly common issue. EDIT: this is not specific to ruby either, could also be requested with PHP when the client wants a magento or laravel project. – Robert Pounder Apr 12 '17 at 12:27
  • Ruby on Rails isn't the only web framework, although it is a pretty good one. Language choice is usually dictated by non-technical reasons. I.e. the majority of the team knows one language, or the ability to recruit in an area is easier if we target one language over another. Still work through the design and make sure the framework doesn't get in the way. – Berin Loritsch Apr 12 '17 at 12:30
  • And if the framework does get in the way and its the requirement of a client? Is it not something you could of avoided in the design? – Robert Pounder Apr 12 '17 at 12:30
  • 3
    Then you need to do some negotiations with the client. Explain what you can and cannot do with the constraints they have imposed. Propose how that can change if you choose X framework. They may not be willing to change and are willing to live with a degraded experience. Or they may decide that you know what you are doing and trust you. That depends on the client. At the end of the day, you manage their expectations. – Berin Loritsch Apr 12 '17 at 12:33
  • I dunno, it just feels in these cases where a specific language is requested then framework SHOULD be taken into consideration because otherwise you get bigger issues later on. It's never going to be "we can't do that because of the framework" but more of "we are using this framework so we COULD do that", the Client should be trusting you to come up with the best solution. But yeh obviously if theres another framework that suits the job better, that should be suggested! Then taken into consideration when redesigning the system? – Robert Pounder Apr 12 '17 at 12:35
  • Remember, you asked for best practice. Customers often say things without knowing the consequences of what they are requiring. I doubt you are going to get into any real meaningful constraints with Ruby on Rails, but I could be wrong. – Berin Loritsch Apr 12 '17 at 12:36
  • My issue is actually in regards to Laravel, I just wanted an unbiased opinion on my bias towards Laravel ;) - Thanks for all your help anyway I guess the answer was the one I didn't want to hear which was, "No, frameworks should not be taken into consideration when designing a system" – Robert Pounder Apr 12 '17 at 12:37
  • 4
    There seems to be some confusion between different levels of design here: system design and detailed design. To me, this question was asking about the detailed design (the implementation method) rather than the system (interfaces, concurrency, data volume, user interface, user type). – Gusdor Apr 12 '17 at 13:03
  • @Gusdor although I ment the question in a detailed design way, it is actually applicable to both sides, and both are very relevant to the question's context and apply to my issue. – Robert Pounder Apr 12 '17 at 14:38
  • My gosh, can't they manage some training for their one developer? I recall being sent off for a week of training on Informix 4GL. (And who is that old guy in the mirror?!?) And no, I never had to use it. –  Apr 12 '17 at 17:52
  • 2
    If the question turns around "technical design", then language and OS may have some inferences in the design. But still, design is not implementation. If you are thinking in Frameworks capabilities, It's not design, It's implentation. If you base your design decitions on the framework strenghts, prepare yourself for suffering its weakness. And when weakness meet requirements, you have a huge problem. The largest companies didn't build theirown frameworks for pleasure. – Laiv Apr 12 '17 at 20:02
  • 1
    @Laiv Great comment! Really, it is "some and some". A nailgun and a screwgun both can fasten stuff, one is more reversible than the other and also works slower and is more complex. Every choice people make is unavoidably a tradeoff. You pays your money and you takes your chances. –  Apr 13 '17 at 00:19
  • @Laiv if you could post that in the form of an answer it'd be the accepted one. – Robert Pounder Apr 13 '17 at 09:37
  • @BerinLoritsch I was explaining this to someone at work, am I correct in assuming that you considered a framework a "tool" that would be decided after designing the system? – Robert Pounder May 10 '17 at 08:57
  • 1
    @RobertPounder, It is a tool who's appropriateness for a solution needs to be decided while designing the system. I understand how frameworks can influence design, but they shouldn't dictate it. – Berin Loritsch May 10 '17 at 11:47
  • @BerinLoritsch Too bad you weren't able to convince people of this 20 years ago in the rush to use the Internet for everything under the sun. As a result, hordes of people have bent and hammered the 'framework' in to whatever shape they felt they needed. I guess the issue was that there was no other tool available to do the job. –  Jun 01 '17 at 14:03
  • @nocomprende, When I stopped working with Java roughly 6+ years ago, there were no less than 100 different web frameworks. The problem wasn't that there weren't enough tools, it was that there were too many and the frameworks were all as opinionated as the writers. Thankfully, now that I'm getting back into Java programming things have calmed down a lot. In contrast, some of the Ruby frameworks and Dot Net frameworks have been much less opinionated so there was less reason to over-defend them. – Berin Loritsch Jun 02 '17 at 17:43
  • I didn't mean frameworks as such, I meant the Internet generally. This 'free' way of delivering content arrived, and of course the most vital thing to do with it was to shove more advertising in front of people. It was not designed for commerce. The biggest 'fail' example I know of is that WiFi was used for public access when it was explicitly not designed to do that securely, because public access was needed, and there was nothing else available. Instead of developing a proper method, the wrong method was jammed in, with predictable results. What to call this? "Negative design" or something? –  Jun 02 '17 at 17:56
27

Frameworks naturally influence the design of specific modules and sub-systems (such as a GUI front-end). As the other answer mentioned, you will have a difficult time if you find yourself fighting against your chosen framework(s).

More broadly however, you should avoid letting any single framework or technology dictate or drive the "big picture" of your overall system architecture. Most general-purpose application frameworks don't encourage this, so if you find yourself writing your entire system around one framework then you're probably doing something the authors of that framework didn't intend.

You will likely use many different frameworks to solve different problems; as your system becomes more complex you need to be careful not to build The Big Ball Of Mud. Where possible, keep your system modular and loosely coupled. Some frameworks might be better kept behind abstractions by writing wrappers and adapters which 'hide' the Framework-specific workflows away from other components. GUI toolkits tend to only serve front-end GUI functionality, so those GUI modules should be kept away from the rest of the system.

General-purpose frameworks (such as UI frameworks, data layer frameworks, etc.) don't exist to prescribe the complete architecture of your system - at most they might prescribe the design of a component or module; for example, some GUI technologies are geared towards particular MV* patterns.

The overall architecture of your system should be primarily driven by your business requirements. You may find yourself leaning heavily on a particular tool (for example, a messaging middleware tool, or an ORM framework) in order to tie everything together, but if you've encapsulated the framework in an abstraction such as a 'service' class you're less likely to find yourself being constrained by that framework when you encounter its limitations.

Try to keep the following in mind for your big-picture design:

Community
  • 1
Ben Cottrell
  • 11,739
  • Sometimes it seems some framework authors don't mind at all having their users writing application code tighty coupled with the framework. – COME FROM Apr 12 '17 at 12:24
  • 2
    @COMEFROM - Tightly coupling your code to a framework would be encouraged by the developers because they assume you chose their framework to solve the same problems they designed it for in the first place. – JeffO Apr 12 '17 at 12:34
  • You went a little off-subject, going from design principles to coding principles, but I get the jist of what your saying, what if the business requirement is that a certain framework be used? (think company out-sourcing and the in-house devs only know one language) I think I should of made this clearer in the original post. – Robert Pounder Apr 12 '17 at 12:46
  • 1
    @RobertPounder The real point I'd been trying to get at (perhaps not very well) is that there is sometimes a tendency for people to use particular frameworks as a 'grounding' for their entire application - which inevitably leads to business logic and other unrelated code being inappropriately fused to that framework - e.g. business logic being coupled with UI controls just because it was quick'n'easy at the time. It's very easy to do that, so it's something to be wary of – Ben Cottrell Apr 12 '17 at 15:29
  • @BenCottrell this is pretty much what my boss and I were discussing, trying to find that middle ground of "using this framework to get the most use out of it possible" and "writing this system that isn't locked down to FRAMEWORKNAMEHERE" – Robert Pounder Apr 12 '17 at 15:39
  • @RobertPounder I agree it's a delicate balancing act, and surely will depend mostly on how much time you have to actually get the job done. I'm sure your priority is to deliver working software within time and budget, so whatever time you can afford to spend on writing abstractions is great to avoid paying that "debt" later. It's worth having frequent progress reviews versus estimates and expected timescales. If you can't deliver the perfect design on time, then it's better to know about it while there's still time to release something which "just works" – Ben Cottrell Apr 12 '17 at 16:23
  • @BenCottrell It's a pretty large scale project with the development estimated at 2 years so it's not something that wouldn't get re-scoped or re-engineered several times anyway. With such a time scale you can see the potential disaster's and requirement to ask this question :)! – Robert Pounder Apr 12 '17 at 16:27
  • People are often concerned about re-use, but when a product gets moved to a new environment, often the only thing that survives is the data. And that gets translated to a new schema during the conversion anyhow. Build it expecting that it will be all be thrown away, and you will never be proven wrong. –  Apr 12 '17 at 17:58
  • 2
    I must disagree with @nocomprende here; not all future requirements can be predicted, *but* sometimes systems are rewritten simply because the previous software is too difficult to extend / maintain. – Seldom 'Where's Monica' Needy Apr 13 '17 at 04:04
  • @SeldomNeedy right, but my point was that the lifetime of all things is finite, and sometimes all that is left at the end is a pile of ashes. Eventually, this is the guaranteed outcome, so don't worry too much about the code's future. It doesn't matter why it happens, because it will. –  Apr 13 '17 at 11:05
  • @nocomprende I don't generally see re-use as being an argument for writing decoupled code. The reason for encapsulating frameworks behind their own abstractions (as opposed to simply throwing together the quickest possible solution) is that it makes the code cheaper to maintain throughout its lifetime. Code often has a much longer shelf-life than most people anticipate; a "quick prototype" which only cost a few man-months to write can end up devouring multiple man-years in terms of future maintenance. Decoupled code reduces technical "debt" and therefore the time/cost of maintenance. – Ben Cottrell Apr 13 '17 at 13:21
  • Continued use, re-use. Can you explain the distinction you are drawing? I do not see one. You mention the 'lifetime' of the code. All I was saying is: don't get attached, because no matter what else the code might be, it is eminently mortal. The Buddha said, "Everything that has a beginning has an ending. Make your peace with that and all will be well." Too bad more programmers and business people are not Buddhist. (India?) (so right... I forgot) –  Apr 13 '17 at 14:02
  • @nocomprende My point is that it's irrelevant; the argument for writing de-coupled code really has nothing to do either with re-use or even length of time that someone might believe the code will exist. Writing de-coupled code is about the fact that code doesn't remain unchanged in its lifetime, it gets maintained and evolves - decoupling helps reduce the time, cost and disruption involved in maintenance - and maintenance tends to cost a lot more than writing code. – Ben Cottrell Apr 13 '17 at 14:15
  • I guess I went off on a tangent, my apologies to you. Something triggered my initial re-use comment, but that was so long ago... I intended to agree with you. I use the term "framework" normally to mean something comprehensive, not a code library. I mean something like SAP or SalesForce (I'm not too familiar with them) - something that literally dictates how you do everything. I think that is actually a better approach. I used to create little domain-specific languages and "runners" for small projects. A Framework is the same only writ large. –  Apr 13 '17 at 14:21
7

Yes, you should stick as closely as possible to what the framework "tells" you to do.

The reason is simply that the closer you stick to the frameworks way of "thinking", the easier you will be able to talk to other developers about your problems/ideas that also use that framework.

You increase interoperability and ease of use for other people that use it later, you will understand and incorporate tutorials or common solutions better if you stick to the underlying philosophy of whatever you're using.

The only good reason I can think of why you would "break" the framework is that you absolutely need something it cannot provide given its "default" configuration/application of principles. But then, it might not be the right framework to begin with.

Basically, this can applied to other decisions as well. You should use the language you're using as closely as it's intended to be used, because it makes things easier if you're talking the same language as everyone else.

F.P
  • 609
  • 4
  • 12
  • May be you should review your answer due to question's changes. Your answer actually doesn't answer the OP's question. – Laiv Apr 12 '17 at 11:44
  • 1
    @Laiv I don't see how it doesn't answer the question, albeit it might not match your opinion on the topic, it's still an answer. You are most welcome to write your own answer to display the conflicting nature of the topic in question. – F.P Apr 12 '17 at 11:51
  • Excuse me if I didn't explain well myself. I'm not as fluent in english as I would like to be. I just wanted to say that, IMO, the question and your answer speak about different things. If you think they don't, It's ok. I won't argue that. That's it. – Laiv Apr 12 '17 at 12:14
  • Yeh it doesnt really touch on my issues with the design implications restricted by a framework, but I get the point your making that the framework should be considered... Food for thought! – Robert Pounder Apr 12 '17 at 12:33
  • 1
    This is absolutely it. It is similar to how Domain-Specific Languages and similar ideas work. Your products are shaped by the tool (Framework) not the other way around. The Framework "wins". If you can't marry it, then choose a different one. (Hint: there is no ideal Framework. Just sayin'.) –  Apr 12 '17 at 18:02
  • 1
    Your design should influence which framework you choose (if any!), not the other way round. – RubberDuck Apr 14 '17 at 10:44
  • @RubberDuck and, available frameworks should influence what type of design you create, else you could be reinventing the weal. Why not take advantage of someone else's hard work? –  Jun 01 '17 at 13:55
  • Yeah. I completely disagree with that notion @nocomprende. If it's greenfield, choose the best design you can (with admittedly imperfect knowledge) then choose the best tools you can for your problem space and business context. If I try to build a car with a hammer, just because I have a hammer in my toolbox, I'll end up with something I probably couldn't call a car. – RubberDuck Jun 01 '17 at 22:37
  • @RubberDuck I think you and nocomprende are on the same page, just on different stages of development. Of course, if you're starting on a blank slate, you'll design first and choose tooling later. However if you have already chosen tools, any new design will inevitably be influenced by the tools you have, because if not, you'll need to do a redesign and again, start with a blank slate.

    But you can also not just dismiss that if you're already familiar with a certain set of tools, you'll likely be more efficient when you design new things with those tools instead of learning new ones.

     – F.P Jun 02 '17 at 06:10
  • @RubberDuck I guess I am thinking that we are already drowning in tools and the results of previous decisions, so what is one more? After all, we don't create our own CPUs or computers (even Google just cobbled together a swarm of off-the-shelf machines to create a server farm), we don't create languages, or compilers, or communications protocols or the ideas of client-server or web-based or or or... So choosing a framework at the start of design is like choosing your boots to ascend Everest: the mountain is already there. Who really cares? You don't have to make your own boots, just buy some. –  Jun 02 '17 at 13:19
  • Better yet, take a helicopter. As Ecclesiastes said thousands of years ago, "Why should you destroy yourself?" We are not in this field to prove how manly (or womanly) we are, but to get work done. –  Jun 02 '17 at 13:21
  • @nocomprende I'm in no way suggesting that we build our own tools from scratch. I'm suggesting that we design before choosing tools. – RubberDuck Jun 02 '17 at 13:48
  • @RubberDuck the tools have already chosen you and your design concepts. "A chicken is an egg's way of making another egg." Resistance is futile. –  Jun 02 '17 at 14:56