I have been examining the code base we use in work and I am worried about the size the packages have grown to. The actual code is modular, procedures have been broken down into small functional (and testable) parts. The issue I see is that we have 100 procedures in a single package - almost an entire domain model.I had thought of breaking these packages down - to create sub domains that are centered around the procedure relationships to other objects. Group a bunch of procedures that have 80% of their relationships to three tables etc. The end result would be a lot more packages, but the packages would be smaller and I feel the entire code base would be more readable - when procedures cross between two domain models it is less of a struggle to figure which package it belongs to.The problem I now have is what the actual benefit of all this would really be. I looked at the general advantages of modularity:1. Re-usability2. Asynchronous Development 3. MaintainabilityYet when I consider our latest development, the procedures within the packages are already reusable. At this advanced stage we rarely require asynchronous development - and when it is required we simply ladder the stories across iterations. So I guess my question is if people know of reasons why you would break down classes rather than just the methods inside of classes? Right now I do believe there is an issue with these mega packages forming but the only benefit I can really pin down to break them down is readability - something that experience gained from working with them would solve.
Modular Database Structures
design patterns;database design;oracle;anti patterns;domain model
Right now I do believe there is an issue with these mega packages forming but the only   benefit I can really pin down to break them down is readabilityWell, IMHO the point you are missing here is better encapsulation. If you are going to add a new feature to a mega package with 100 functions, you may have to check for side effects or similar things in all those 100 functions (YMMV depending on the actual problem). If you split your package before into 5 smaller packages, you can probably handle such a change more easily, since it may impact a smaller area of your code.However, when you only seldom change your packages and functions, you have to consider if such a refactoring is worth the trouble - a big refactoring should never be applied just for the sake of itself. And I guess you don't have any refactoring browser for PL/SQL which could assists you (does such a thing exist?), so such a restructuring could mean a lot of work.