12

I am in the design stage of a web application that allows users to create requests of work and the workers to put time against those requests. The application will also have reporting capabilities for supervisors to get daily totals, reports, and account for time spent, "cost allocation".

Applications I've worked on in the past have been designed using the package by layer approach. I'm thinking it would be more efficient to use a package by feature design and I have a question about this design.

What I am currently thinking for the packages by feature:

  1. Requests - CRUD the requests, assign then, add invoice numbers, etc...
  2. Work Time - CRUD daily time for users against requests, holiday, training, or meetings
  3. Cost Allocation - create reports, accounting things that accountants want ...

The front-end will be Tomcat server and JSP. And, the back-end will be an Oracle database with EclipseLink doing the persistence.

My question:

In my understanding of package by feature, the entities and DAOs would go into the package associated with them. Spreading out the persistence layer across several packages. Leaving packages to call entities from other packages. With all of the overlap is this really functional? There would be no isolation between the packages. What are the pros and cons to using package by feature? Would it be good design to go with an additional persistence layer? Or, do I have the understanding of this totally wrong?

Sisyphus
  • 4,181
  • 1
  • 22
  • 15
Miller
  • 481
  • 1
  • 6
  • 18

3 Answers3

8

5 years later...

(Suspenseful music in the background)

Imagine this ridiculous situation:

Managers company, Programmers company, Human Resources company and Marketing company, where the Programmers company will only have programmers and no managers, marketeers or human resources;

We wouldn't want to split co-workers by their profession instead of organizing (self-coordinating) teams, or would we?

Packaging stuff together by what it is, and not by what it does, will only make you jump 10 times to the place you are looking for.

Package by feature, not layers.

Now doesn't that just look sexy? By looking at the structure, you can already tell what the app is all about. Not satisfied? Read full article.

Community
  • 1
  • 1
5

I would suggest to start package things based on business entities. And in there you can divide things based on layers.

With all of the overlap is this really functional?

I am practising it for long. I don't see any major issues with this approach. You must find out what to decouple and how much it should be decoupled. For example, calling a persistent method of orders from a customer package using the API provided by orders is pretty fine for me.

What are the pros and cons to using package by feature?

I find it more simple, straight, understandable and easy to work with than strict layer oriented packaging. It benefits when you want to split and distribute things to different places.

Would it be good design to go with an additional persistence layer?

Look at this SO thread, I found JPA, or alike, don't encourage DAO pattern.

Further Reading

Community
  • 1
  • 1
Adeel Ansari
  • 39,541
  • 12
  • 93
  • 133
  • I understand what you mean. I've thought about getting rid of the DAO layer but am having issues how to do it. In the book DDD by Eric Evans he talks about using the repository pattern. Does this provide similar functionality to DAO? I'm still grasping at the concepts so please excuse my noob. Also, is there a good code example around to get a better picture of DDD? – Miller Jun 07 '11 at 05:19
  • @Miller: Yes, somewhat similar. The client creates query using expression API or declaratively and pass it to the repository for satisfaction. You can think of JPA as a DAO layer, as suggested in the thread, I provided. – Adeel Ansari Jun 07 '11 at 05:57
  • Then the entity manager would be injected into repository, correct? That would allow JPA functionality at that layer. – Miller Jun 07 '11 at 06:04
  • @Miller: The entity manager would be injected into your business component and work as a repository for your business component. Think of JPA as an implementation of repository pattern. Moreover, I have added a link to my original answer above. – Adeel Ansari Jun 07 '11 at 07:08
  • @AdeelAnsari Do you have some links of manuals and references for demonstrating **how to package things based on business entities**? – Iman Mahmoudinasab Mar 07 '15 at 08:16
1

If I would chose betwen the two package by feature vs package by layer. I would chose package by layer.

For several reason,

  • In layered arhcitecture the interfaces/depenencies should be clearly defined between layers, appropriate packaging will quickly highlight if you are intrudicing un-wanted dependencies or not
  • It isolates dependencies in one layer (for example persistance using Oracle) from your other layers.
  • I find it cleaner to think of each layer in isolation

But to answer your question Features vs. Layers or both, I would say both, package primarily by layers then by features.

hhafez
  • 38,949
  • 39
  • 113
  • 143
  • What about entities that are used in all the features? Example: Requests are CRUD in the Requests package. They are then used to put time against in Work Times and reported against in Cost Allocation. I assume that they would be defined once with all the look up tables in the Requests package and used as objects in the other packages. Would that then put the look up code in the Requests package that the other packages would be using? – Miller Jun 07 '11 at 05:13
  • 1
    For entities that are used across layers, I would consider having a "framework" package that doesn't provide features in of itself but enables the reuse of common code across layers. – hhafez Jun 07 '11 at 05:26
  • Like an domain package? In it would be the Request, Work Time objects plus the look up table entities? Or am I missing the point? – Miller Jun 07 '11 at 05:56
  • @Miller - I don't get it. Your argument, while valid, seems to speak precisely against packaging by feature, not by layer (which is what hhafez advocated). – Konrad Morawski Nov 24 '14 at 11:25