Okay, so by convention, you'd have a module with filename "Foo/Bar.pm" and in that you'd define a package called Foo::Bar. That's just a convention though! "Foo/Bar.pm" can define a package called "Foo".

Foo.pm

package Foo;
require Foo::Bar; # load additional methods
sub aa {
  my ( $self, $args ) = @_;
  my $val = $self->_aa ( $args->{'bar'} );
}
sub bb {
  my ( $self, $args ) = @_;
  my $val = $self->_bb ( $args->{'foo'} );
}
1;
[download]

Foo/Bar.pm

package Foo;  # not Foo::Bar!!!
sub _aa {
  my ( $self, $quux ) = @_;
  ...;
}
sub _bb {
  my ( $self, $fazoo ) = @_;
  ...;
}
1;
[download]

Also, you don't need to do your require Foo::Bar thing right at the top of Foo.pm like I did in my examples. You could do something like:

sub aa {
  my ( $self, $args ) = @_;
  require Foo::Bar;
  my $val = $self->_aa ( $args->{'bar'} );
}
[download]

… which will load the additional methods right before they're needed instead of right at the start. If those private methods are uncommonly used (for example, they're used in debugging and diagnostics only, and normal executions of the program don't need them) then this might be a good idea, because you can skip loading, parsing, and compiling those methods most of the time. If the methods are going to be used all/most of the time, you'll get better performance from a single require Foo::Bar at the top of Foo.pm.

I go to even more extremes to split up my CPAN module Types::Standard. Some of the methods defined in that are instead blessed objects overloading coderefification which when they're first called, load their real code from another module, and replace themselves. It's pretty rare that you'd want to go to those extremes, but it makes sense for Types::Standard.