Naming things/structure

[davidmarkclements]

1. "service/lib/service.js" - What else goes in lib? Libraries that support service.js, service.js is the entry point it should go above lib:
2. "service/service.js" seems redundant, default entry point is index.js, so why not service/index.js?
3. "wiring-mu" - this about route configuration right? Can we call it "routing.js" or "config.js"/"cfg.js"
4. test/service/{name}Test - its in the test folder what need is there for the test suffix
5. Should service tests maybe go in service folder (service/test instead of test/service) ?
6. "integration -> component" I think that sends the right message (this is a component not an app) (undrestand what integration is now)
7. integration/services.js is analogous to mu-wiring - can this be routing.js or config.js/cfg.js
8. frontend -> component I think that sends the right message (this is a component not an app)

---

edit: revisions

[piccoloaiutante]

1. agreed
2. yep lets go for indie.js
3. to me it's not about configuration but about having a set of way that you can use to expose your business logic. Maybe moving all wirings in a wiring folder?
4. i haven't fully understood
5. we agreed with @pelger to have a test folder that matches the project structure
6. :-)
7. integration/services.js should be the module in charge of loading the desired wiring (mu, bus or whatever). Should we go for an a integration/service/index.js ?
8. agreed

@davidmarkclements ^

[davidmarkclements]

1. Yay
2. index* & yay
3. I think separating between pattern routing and command definitions is important - pattern routing is confit whereas command definitions is exposing business logic - maybe they should be separated into routing.js and wiring.js?
4. test/service/lib/serviceTest.js -> test/service/lib/service.js (if its in the test folder we know it's a test? Fixtures/helpers should be in sep folder or ideally their own modules)
5. Ok fair enough
6. :-P
7. .. I think that sounds good
8. Yay