一个项目现在有200多个类,每个文件一个类,将它们分成目录似乎是恰当的。现在我在考虑两种不同的策略;
a)按角色或图层分组
repositories/
UserRepository
TransactionRepository
ShipmentRepository
serializers/
UserSerializer
TransactionSerializer
ShipmentSerializer
models/
User
Transaction
Shipment
b)按类服务的域模型进行分组
user/
UserRepository
UserSerializer
User
transaction/
TransactionRepository
TransactionSerializer
Transaction
shipment/
ShipmentRepository
ShipmentSerializer
Shipment
b)的优点可能是倾向于一起改变的类被组合在一起,而在a)具有相似内部工作的类可以被组合在一起。你会建议什么?
答案 0 :(得分:4)
就个人而言,我不喜欢aproach A.这些目录之间存在很强的依赖关系。其中一些是不必要的,并使依赖难以加班。
例如: 初级开发人员增加对UserRepository的依赖 - >装运,但这在设计上是不可取的。该漏洞很难被发现(除非经过仔细的代码审查),因为存储库确实依赖于UserRepository的模型 - >用户。
但这在方法B中要容易得多。我们可以在目录上应用一些依赖性检查策略(禁止用户 - >发货)。
依赖管理的粒度非常重要。如果我们可以通过一些自动检查工具在较粗糙的水平上管理它,那么成本要低得多。