Program Design - Package by Feature vs. Layer or Both?

前端 未结 3 416
暗喜
暗喜 2020-12-05 16:18

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

相关标签:
3条回答
  • 2020-12-05 16:41

    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.

    0 讨论(0)
  • 2020-12-05 16:54

    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

    • Generic Repository and DDD
    0 讨论(0)
  • 2020-12-05 17:00

    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.

    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.

    0 讨论(0)
提交回复
热议问题