title: Angular Project Structure For Enterprise Projects
body: <p>I'm about to start a fairly large project that will use Angular for it's front end and I had a question about how to manage it's growth to maximize maintainability.  </p>
  
  <p>For every angular project up until this point, I've had a views folder that mimics the routing hierarchy and my module structure has been based off of grouping of business feature.  This has worked well with onboarding new devs and for maintenance purposes for these small to mid-size apps.  </p>
  
  <p>My question centers more around when to use modules in a large enterprise app. </p>
  
  <p>I've recently heard about creating a module per page and/or module per component.  This approach seems like a ton of up front overhead but a lot of savings in test creation and long term maintenance.  </p>
  
  <p>I don't see any guidance in the angular.io style guide regarding one way or another but I'd like to know from people that have built enterprise sized angular applications if they've found a particular way that works well for them.  </p>
  
  <p><strong>UPDATE</strong>
  I got a lot of great answers here.  I believe that all emphasized the common points of module by feature and extra modules for the core, shared (and resources that bryan mentioned).  I am also going to move my routing views into their respective feature folder as opposed to the "views" folder that I currently use.  After reading the answers below, the "views" folder might get tricky to manage down the road as the application grows.</p>
  
  <p>Someone had also suggested I read up on what Nrwl is doing and so I did that and was intrigued by their usage of libraries as separate from the app.  <a href="https://connect.nrwl.io/app/books/enterprise-angular-monorepo-patterns" rel="nofollow noreferrer">Nrwl MonoRepo Pattern Book (Free)</a> .  They had a lot of good advice that ran parallel to what everybody said here with the addition of abstracting away common functionality across platforms into libraries.  Since I am sure the app I am building will require targeting mobile devices outside of the web world, this seemed like a good idea as well.  </p>
  
  <p>Thank you to everybody that took the time to respond in great detail. </p>