 <p>I agree with the comment from Korri above, in that you could benefit from taking inspiration from existing frameworks.</p> <p>Personally, this sort of directory structure feels right, to me.</p> <pre><code>. |-- composer.json |-- gulpfile.js |-- package.json |-- changelog.md |-- readme.md |-- /src (This is the API code that *I'm* responsible for, and that I *own*.). | |-- /app | | |-- /controllers | | |-- /models | | `-- &lt;other_framework_stuff&gt; | /public (Keeping this outside of the src dir, means that you can give this to your front-end devs without needing to have the entire codebase). | | |-- /styles | | |-- /images | | |-- /js | /config (Put all configuration files outside of the src scope, so you can keep it outside of source control) | /build (CI build related configuration) | | |--phpcs.xml | | |--phpdocx.xml |-- /tests (separating out your tests in this way can help you run tests separately, more easily) | | |--acceptance | | |--integration | | |--unit |-- /vendor (Depenedencies installed via Composer) </code></pre> <p>Really, there's no community driven correct answer to your question. The correct answer is specific to <em>your</em> business, the team <em>you</em> work in, and the project itself. </p> <p>I'd never put the <code>/vendor</code> directory within your <code>/src</code> directory - because you don't <em>own</em> it. You're not responsible for the changes to the code within your project's dependencies, so it should be left in its own scope outside of your projects walls.</p> <p>With <a href="http://www.php-fig.org/psr/psr-4/" rel="nofollow">PSR-4</a> autoloading, it really doesn't matter too much about your directory structure, it can be changed easily at any time, with no impact on your code. So, experiment and see what <em>feels</em> right for you.</p>