ZXappz::Database anyway because it can contains for example store_new_user and store_action_for_user and so on...

:) That is good thinking, separate the stuff, groupt the database stuff together

but the name should be different from "database" because that is kind of stuff that goes in your "model",

so you might have a ZXappz::UserGroup (or ZXappz::Model::UserGroup) with a add_user and ...

yes it goes in a database, maybe one created from ZXappz::Schema::UserGroup ...

but you call it something important to your app, symbolic not generic

Its like when you first learn programming, no subroutines, just long stretches of code, you have to start somewhere

then the next evolution, you start using subroutines, but its still one file, and they're very long and do too much, and the names are focused on the implementation details

then you start making packages, which is great, but you're organizing principle is not the intent of the code but implementation detail;

Is this terrible? No. Its common, its workable, its maintainable, esp for short programs, but could be improved; and should be improved , esp if you want to reuse the code, and for others to use your code , and enjoy it (collaboration )

There is no reason to take the long way around, jump straight to intent :) organize stuff with big picture in mind, like a house, you have to frame it, but you don't design around the frame, around stud, you design around rooms with purpose, by walking around the house in your head, wake up in the morning, get ready for work, host a party...

start with a story board, how should the user use the application, what should it do

then start with use cases, how should the code be used by the programmer, write that code, and your api will emerge