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?

  • Unclear what help you need. Please clarify your specific problem or provide additional details to highlight exactly what you need. As it's currently written, it’s hard to tell what problem you are trying to solve or what aspect of your approach needs to be corrected or explained. See the How to Ask page for help clarifying this question.
    – gnat
    Commented Mar 7, 2014 at 14:38
  • @gnat - my specific problem is which approach (of the two I've outlined) to use to architect my app. "How to Ask" doesn't have much info. An example of a useful answer would be "Organise by technical function, because..."
    – paj28
    Commented Mar 7, 2014 at 15:07
  • meta.programmers.stackexchange.com/questions/6483/…
    – gnat
    Commented Mar 7, 2014 at 15:22
  • 1
    @gnat - edited; is that any better?
    – paj28
    Commented Mar 7, 2014 at 15:30
  • 2
    The proper terms are "solution domain" for "technical function" and "problem domain" for "business function." As you've seen, software architecture belongs to the solution domain (that's why it's called that)
    – user16764
    Commented Mar 7, 2014 at 15:52

1 Answer 1


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.