Question

So, here’s a quick extract of the directory structure on a web application that I am working on currently:

/app
  /libraries
    User_Input.php
    Database.php
    InvoiceHandler.php

Do you think that the InvoiceHandler is a bit odd in this collection? I sure do.

Until recently, I have ignored the need to distinguish between de-facto libraries that actually are the middle-layer between my application and other services (such as a Persistent storage) and the classes of code that I have written myself that contains custom logic for my application (such as the Invoice_Handler in this case).

But as my application grows, this creates more and more of a mess. I haven’t seen any good examples on this as of today and I have not enough experience to come to a conclusion by myself:

What does conventions and common sense say on separation of these two definite and so clearly different sort of classes?

Answer 1

I ended up separating my libraries depending on what level of abstraction they contained. In search of a better name of high-level abstraction, I used the category name services for these and retained with libraries for low-level abstraction classes.

Ie. :

/common
    /libraries (low-level)
        database.php
        session.php
        email.php
    /services (high-level)
        auth.php (dependent on database + session)
        invoicing.php (dependent on database + email)