I am designing a large application (a static code analyser) and I have a choice in how to organise the code into modules:One approach is by what I'd call by technical function. This is where you have a package for data objects, another for service functions, views, controllers, etc.Another approach is what I'd call by business function. This where you'd have a package for, say, stock control, another for product listings, customer orders, etc.Most frameworks tend to push me towards the first approach. Sometimes there are technical reasons for this, e.g. if the view is written in JavaScript and the rest in Python, you really need to keep it separate. But mostly it is just a matter of convention.Sometimes organising by technical function results in spreading related code across the application. If I have code to support a product, I end up with ProductModel, ProductService, ProductView, etc. Often I feel it would be neater to simply have a Product object that does all these.Organising by business function has issues too. Some classes are borderline and it's quite arbitrary which package you put them in. And there are some support objects that are used across all business functions.Which approach will be the most effective for making a scalable and maintainable application?
Organisation by business function vs technical function
architecture;organization
I usually organize by business function (problem domain).  If you are trying to use objects to represent relationships between things in the real world, then Products, Orders, etc. more directly map to what the user knows (the domain language) and should be more intuitive for you to discuss, write, and maintain.There will always be cross-cutting concerns.  Easy examples would be exceptions, logging, and database connections.  You can usually extract those services to objects or interfaces of their own.Essentially you end up with two types of classes: domain specific objects (products, orders) and cross-cutting objects (exceptions, persistence, data views).  I don't know if this is the official best-practice, but you can see a similar concept in the .NET framework organization.  Domain-specific objects would be like Strings, Data Adapters, etc.  Cross-cutting objects and interfaces would be like IEnumerable or Exceptions.