Project directory structure

Question

Over my years of practice and through most of the reading I've done, the oft recommended directory structure for a web app project has been closely tied to the MVC structure:

tests/
src/
  styles/
  markup/
  scripts/
    views/
    models/
    controllers/

However, I've recently started working in a new company, and their project repositories are oddly structured (odd to me). The devs explained that they find this feature-structure easier to comprehend (I don't know what this project structure is really called). It goes something like this:

app/
src/
  component1/
    test
    view
    model
    controller
  component2/
    test
    view
    model
    controller

Of course, some components don't have the view, model, controller files because they're more akin to independent modules or business logic, than a chunk of MVC architecture. In my opinion, this makes the structure less intuitive.

Can anyone shed some light on this? I feel that my view of the situation is biased because I've always worked in MVC-ish / flux-like app structures.

Are there advantages to this structure, or is it just the result of some devs' foibles and inexperience?

Keep in mind The projects in question are a mix of web apps and web services.

edit: Would this question be more relevant to https://softwareengineering.stackexchange.com/ ?

Answer 1

The structure of the projects at your new company shows signs of modular design, though it is difficult to tell, since your example doesn't contain real names of components/modules. If the module names do not suggest some intuitively comprehensible architecture, then the problem may be that the projects at your new company are victims of Conway's law, which states that

organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations

Conway's law is a result of each team's tendency to outline its own territory, where it can enjoy more freedom, without needing to coordinate every change with everyone else. Often this leads to some lower level functionality duplicated across "modules" belonging to different teams.

Another problem with modular structure can be that partitioning of a large system into components can be done from different perspectives, and applying the wrong one can introduce unneeded complexity. For example, how would you decompose an Animal?

1. By body parts (head, torso, legs, tail, etc)?
2. By "layers" (bones, muscles, nerves, skin, etc)?
3. Both ways (an animal is made of body parts, each of which is made of bones, muscles, etc)?

When done wrong, modular design can cause more harm than good, because it defines a framework, which will constrain your thinking about the system. However, it is above any argument that large systems cannot exist without some form of an architecture.