Organizing Database Objects in a Database that are not part of the systems original Database Objects?
On one hand, a sensible naming convention can solve part of your problem. 

However, a more sophisticated solution is to use schemas: they are a good way to organize your stuff and also make you able to set access rights at this level.

For example, we usually create a data schema (named after the covered functionality and suffixed with '_data') and one or more API schemas.  Tables, the types used for their columns, triggers along with their procedures, sequences and so on all go into the data schema.  As applications are allowed to call API functions only (no arbitrary SQL is allowed), it just makes sense to put all of them into a separate schema, this is what I refer as API schema above.  There may be further ones (utility schema, versioning schema and so on), too.

Of course, your needs may be different, but I hope this illustrates well how schemas can be used.

In your case it is probably better to create schemas mapping the functional grouping.  Then you issue a

CREATE SCHEMA task1_views;


command, and create the objects either with specifying the schema, like

CREATE OR REPLACE VIEW task1_views.important_view ...


or set the search_path first, if you create many objects in a row:

SET search_path TO task1_views;
CREATE OR REPLACE VIEW important_view ... -- no schema specified