原文地址:Package by feature, not layer

Package by feature, not layer

The first question in building an application is "How do I divide it up into packages?". For typical business applications, there seems to be two ways of answering this question.

软件开发首先要处理的事情包括对package进行划分

Package By Feature

Package-by-feature uses packages to reflect the feature set. It tries to place all items related to a single feature (and only that feature) into a single directory/package. This results in packages with high cohesion and high modularity, and with minimal coupling between packages. Items that work closely together are placed next to each other. They aren't spread out all over the application. It's also interesting to note that, in some cases, deleting a feature can reduce to a single operation - deleting a directory. (Deletion operations might be thought of as a good test for maximum modularity: an item has maximum modularity only if it can be deleted in a single operation.)

高内聚、模块化、和其它package之间最小耦合

In package-by-feature, the package names correspond to important, high-level aspects of the problem domain. For example, a drug prescription application might have these packages:

com.app.doctor
com.app.drug
com.app.patient
com.app.presription
com.app.report
com.app.security
com.app.webmaster
com.app.util
and so on...

Each package usually contains only the items related to that particular feature, and no other feature. For example, the com.app.doctor package might contain these items:

DoctorAction.java - an action or controller object
Doctor.java - a Model Object
DoctorDAO.java - Data Access Object
database items (SQL statements)
user interface items (perhaps a JSP, in the case of a web app)

It's important to note that a package can contain not just Java code, but other files as well. Indeed, in order for package-by-feature to really work as desired, all items related to a given feature - from user interface, to Java code, to database items - must be placed in a single directory dedicated to that feature (and only that feature).

In some cases, a feature/package will not be used by any other feature in the application. If that's the case, it may be removed simply by deleting the directory. If it is indeed used by some other feature, then its removal will not be as simple as a single delete operation.

That is, the package-by-feature idea does not imply that one package can never use items belonging to other packages. Rather, package-by-feature aggressively prefers package-private as the default scope, and only increases the scope of an item to public only when needed.

Package By Layer

The competing package-by-layer style is different. In package-by-layer, the highest level packages reflect the various application "layers", instead of features, as in:

com.app.action
com.app.model
com.app.dao
com.app.util

Here, each feature has its implementation spread out over multiple directories, over what might be loosely called "implementation categories". Each directory contains items that usually aren't closely related to each other. This results in packages with low cohesion and low modularity, with high coupling between packages. As a result, editing a feature involves editing files across different directories. In addition, deleting a feature can almost never be performed in a single operation.

Recommendation: Use Package By Feature

For typical business applications, the package-by-feature style seems to be the superior of the two:

Higher Modularity

As mentioned above, only package-by-feature has packages with high cohesion, high modularity, and low coupling between packages.

Easier Code Navigation

Maintenance programmers need to do a lot less searching for items, since all items needed for a given task are usually in the same directory. Some tools that encourage package-by-layer use package naming conventions to ease the problem of tedious code navigation. However, package-by-feature transcends the need for such conventions in the first place, by greatly reducing the need to navigate between directories.

Higher Level of Abstraction

Staying at a high level of abstraction is one of programming's guiding principles of lasting value. It makes it easier to think about a problem, and emphasizes fundamental services over implementation details. As a direct benefit of being at a high level of abstraction, the application becomes more self-documenting: the overall size of the application is communicated by the number of packages, and the basic features are communicated by the package names. The fundamental flaw with package-by-layer style, on the other hand, is that it puts implementation details ahead of high level abstractions - which is backwards.

Separates Both Features and Layers

The package-by-feature style still honors the idea of separating layers, but that separation is implemented using separate classes. The package-by-layer style, on the other hand, implements that separation using both separate classes and separate packages, which doesn't seem necessary or desirable.

Minimizes Scope

Minimizing scope is another guiding principle of lasting value. Here, package-by-feature allows some classes to decrease their scope from public to package-private. This is a significant change, and will help to minimize ripple effects. The package-by-layer style, on the other hand, effectively abandons package-private scope, and forces you to implement nearly all items as public. This is a fundamental flaw, since it doesn't allow you to minimize ripple effects by keeping secrets.

Better Growth Style

In the package-by-feature style, the number of classes within each package remains limited to the items related to a specific feature. If a package becomes too large, it may be refactored in a natural way into two or more packages. The package-by-layer style, on the other hand, is monolithic. As an application grows in size, the number of packages remains roughly the same, while the number of classes in each package will increase without bound.


If you still need further convincing, consider the following.

Directory Structure Is Fundamental To Your Code

"As any designer will tell you, it is the first steps in a design process which count for most. The first few strokes, which create the form, carry within them the destiny of the rest." - Christopher Alexander

(Christopher Alexander is an architect. Without having worked as programmer, he has influenced many people who think a lot about programming. His early book A Pattern Language was the original inspiration for the Design Patterns movement. He has thought long and hard about how to build beautiful things, and these reflections seem to largely apply to software construction as well.)

In a CBC radio interview, Alexander recounted the following story (paraphrased here): "I was working with one of my students. He was having a very difficult time building something. He just didn't know how to proceed at all. So I sat with him, and I said this: Listen, start out by figuring out what the most important thing is. Get that straight first. Get that straight in your mind. Take your time. Don't be too hasty. Think about it for a while. When you feel that you have found it, when there is no doubt in your mind that it is indeed the most important thing, then go ahead and make that most important thing. When you have made that most important thing, ask yourself if you can make it more beautiful. Cut the bullshit, just get it straight in your head, if you can make it better or not. When that's done, and you feel you cannot make it any better, then find the next most important thing."

What are the first strokes in an application, which create its overall form? It is the directory structure. The directory structure is the very first thing encountered by a programmer when browsing source code. Everything flows from it. Everything depends on it. It is clearly one of the most important aspects of your source code.

Consider the different reactions of a programmer when encountering different directory structures. For the package-by-feature style, the thoughts of the application programmer might be like this:

  • "I see. This lists all the top-level features of the app in one go. Nice."
  • "Let's see. I wonder where this item is located....Oh, here it is. And everything else I am going to need is right here too, all in the same spot. Excellent."

For the package-by-layer style, however, the thoughts of the application programmer might be more like this:

  • "These directories tell me nothing. How many features in this app? Beats me. It looks exactly the same as all the others. No difference at all. Great. Here we go again..."
  • "Hmm. I wonder where this item is located....I guess its parts are all over the app, spread around in all these directories. Do I really have all the items I need? I guess we'll find out later."
  • "I wonder if that naming convention is still being followed. If not, I will have to look it up in that other directory."
  • "Wow, would you look at the size of this single directory...sheesh."

Package-By-Layer in Other Domains is Ineffective

By analogy, one can see that the package-by-layer style leads to poor results. For example, imagine a car. At the highest level, a car's 'implementation' is divided this way (package-by-feature) :

  • safety
  • engine
  • steering
  • fuel system
  • and so on...

Now imagine a car whose 'implementation' under the hood is first divided up according to these lower level categories (package-by-layer) :

  • electrical
  • mechanical
  • hydraulic

In the case of a transmission problem, for example, you might need to tinker around in these three compartments. This would mean moving from one part of the car to another completely different one. While in these various compartments, you could 'see' items having absolutely nothing to do with problem you are trying to solve. They would simply be in the way, always and everywhere distracting you from the real task at hand. Wouldn't it make more sense if there was a single place having exactly what you need, and nothing else?

As a second example, consider a large bureacracy divided up into various departments (package-by-feature):

  • front office
  • back office
  • accounting
  • personnel
  • mail room

If a package-by-layer style was used, the primary division would be something like :

  • executives
  • managers
  • employees

Now imagine the bureacracy being divided physically according to these three categories. Each manager is located, for example, with all the other managers, and not with the employees working for them. Would that be effective? No, it wouldn't.

So why should software be any different? It seems that package-by-layer is just a bad habit waiting to be broken.

The example applications that come with WEB4J uses the package-by-feature style.

(本文使用Atom编写)

转载:Package by feature, not layer的更多相关文章

  1. [转载]Browser Link feature in Visual Studio Preview 2013

    http://blogs.msdn.com/b/webdev/archive/2013/07/29/10430221.aspx Browser Link feature in Visual Studi ...

  2. 清晰架构(Clean Architecture)的Go微服务: 程序结构

    我使用Go和gRPC创建了一个微服务,并试图找出最佳的程序结构,它可以用作我未来程序的模板. 我有Java背景,并发现自己在Java和Go之间挣扎,它们之间的编程理念完全不同.我写了一系列关于在项目工 ...

  3. 【论文阅读】Batch Feature Erasing for Person Re-identification and Beyond

    转载请注明出处:https://www.cnblogs.com/White-xzx/ 原文地址:https://arxiv.org/abs/1811.07130 如有不准确或错误的地方,欢迎交流~ [ ...

  4. 转载 - CNN感受野(receptive-fields)RF

    本文翻译自A guide to receptive field arithmetic for Convolutional Neural Networks(可能需要FQ才能访问),方便自己学习和参考.若 ...

  5. Layui 弹出层组件——layer的模块化开发实例应用

    Layui 弹出层组件——layer的模块化开发实例应用 1.首先在package.json中引入layer组件依赖 2.在源码中应用这个依赖 3.在源码中编写代码应用此组件 4.效果验证:点击日历上 ...

  6. Paper | Recovering Realistic Texture in Image Super-resolution by Deep Spatial Feature Transform

    目录 故事背景 空域特征转换 超分辨率网络 发表在2018年CVPR. 摘要 Despite that convolutional neural networks (CNN) have recentl ...

  7. (转载)人脸识别中Softmax-based Loss的演化史

    人脸识别中Softmax-based Loss的演化史  旷视科技 近期,人脸识别研究领域的主要进展之一集中在了 Softmax Loss 的改进之上:在本文中,旷视研究院(上海)(MEGVII Re ...

  8. SSL (Secure Sockets Layer)

    本文转载自SSL (Secure Sockets Layer) TLS简介 The Transport Layer Security (TLS) protocol aims primarily to ...

  9. java项目的划分方式:模块优先还是层优先?

    I've seen and had lots of discussion about "package by layer" vs "package by feature& ...

随机推荐

  1. ES查询-term VS match (转)

    原文地址:https://blog.csdn.net/sxf_123456/article/details/78845437 elasticsearch 中term与match区别 term是精确查询 ...

  2. Tigase8.0 源代码分析:一、启动篇

    Tigase8.0 引用了IoC(控制反转)和DI(依赖注入) 等技术手段,来对对象的创建和控制.不懂的百度下就知道了,Spring完美的实现IOC ,贴一段解释: 通俗地说:控制反转IoC(Inve ...

  3. python 09 文件操作

    一 流程: #1. 打开文件,得到文件句柄并赋值给一个变量 #2. 通过句柄对文件进行操作 #3. 关闭文件 二 例子 #1. 打开文件,得到文件句柄并赋值给一个变量f=open('a.txt','r ...

  4. UI行业发展预测 & 系列规划的调整

    又双叒叕拖更了,上一篇还是1月22号更新的,这都3月9号了…… 前面几期把职业规划.能力分析.几个分析用的设计理论都写完了,当然实际工作中用到的方法论不止上面这些,后续会接着学习: 如果你的目标是一线 ...

  5. GPS坐标系

    本次测试之坑,人车定位偏差,分析如下 车的定位由后台提供,由gps上报位置,采用WGS-84坐标系 前端(app/小程序)使用腾讯地图,或者高德地图,采用的是GCJ-02坐标系,或者在GCJ-02基础 ...

  6. tomcat 请求处理流程分析(基于nio)

    在这里我先简单的说下bio和nio的区别 这里我以电话客服的情况来解释 bio 一个客户对应一个客服, 假如客户比较麻烦,中途不挂电话,或者去做其他事情了,而客服资源会被一直占用 导致的后果是系统处理 ...

  7. 抖音分享和授权(iOS)

    准备工作 注册appkey 抖音开放平台 集成sharesdk 下载地址 Xcode配置:urlScheme为注册的appkey, 白名单:douyinsharesdk ,douyinopensdk ...

  8. d3.js画折线图

    下载d3.zip,并解压到网页文件所在的文件夹 windows下,在命令行进入网页文件夹,输入 python -m http.server 在浏览器中输入127.0.0.1:8000/xxx.html ...

  9. js做的轮播图

    以下那些注释呢,都是要靠自己理解才是最重要的, <!DOCTYPE html> <html> <head> <meta charset="utf-8 ...

  10. Effective C++ 笔记:条款 34 实现继承和接口继承

    Differentiate between inheritance of interface and inheritance of implementation. 行为含义 声明一个pure virt ...