4

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?

Improve this question
5
  • 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. 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..." Commented Mar 7, 2014 at 15:07
  • meta.programmers.stackexchange.com/questions/6483/… Commented Mar 7, 2014 at 15:22
  • 1
    @gnat - edited; is that any better? 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) Commented Mar 7, 2014 at 15:52

1 Answer 1

Reset to default
3

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.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.