Frage

A project now has over 200 classes, one class per file, and it seems pertinent to divide those up into directories. Now I am thinking of two different strategies;

a) grouping by role or layer

repositories/
    UserRepository
    TransactionRepository
    ShipmentRepository
serializers/
    UserSerializer
    TransactionSerializer
    ShipmentSerializer
models/
    User
    Transaction
    Shipment

b) grouping by the domain model that the class serves

user/
    UserRepository
    UserSerializer
    User
transaction/
    TransactionRepository
    TransactionSerializer
    Transaction
shipment/
    ShipmentRepository
    ShipmentSerializer
    Shipment

The advantage of b) perhaps being that classes that tend to change together are grouped together, whereas in a) classes with similar inner workings may be grouped together. What would you suggest?

War es hilfreich?

Lösung

Personally, I don't like aproach A. There are strong dependencies between these directory. Some of them are unneccesary and make dependencies difficult to manage overtime.

For example: A junior developer add dependence on UserRepository --> Shipment, but this is not desirable on design. The flaw is hard to detect(unless with careful code review) since repository does depend on model for UserRepository --> User.

But this is much easier in aproach B. We could apply some dependence-checking strategy on directory( forbidding user --> shipment).

The granularity of dependence management is very important. The cost are much lower if we could manage it at a coarser level by some automatic checking tool.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top