Package indeling per feature of per layer?

[Standeman]

Aangezien ik bezig ben een nieuwe project op te zetten krijg ik gelijk de de kans om alles even lekker om te gooien t.o.v. onze oude projecten. In mijn zoek tocht ben ik op een "enorm" dilemma gestuit Gaan we packages per layer organiseren of per feature? Ik moet eerlijk bekennen dat ik er nooit zo over nagedacht heb en het altijd per layer gedaan heb.

Voor de mensen die geen idee hebben waar ik het over heb, packages per layer:

1. net.tweakers.view
2. net.tweakers.services
3. net.tweakers.model
4. net.tweakers.persistence

Bovenstaande gebruikten tot voor kort. Nu heb ik de kans om de boel "per feature" te organiseren:

1. net.tweakers.user
2. net.tweakers.fora
3. net.tweakers.pricewatch
4. etc

Aangezien er op het grote boze internet meerdere meningen zijn ben ik benieuwd of iemand hier wel eens veranderd is van methode en waarom? Mijn lijkt het laatste wel handig, aangezien je niet door je hele directory structuur hoeft te bladeren wanneer je aan "users" werkt (bijv. veldjes toevoegen).

[ Voor 4% gewijzigd door Standeman op 20-01-2014 14:50 ]

[Hydra]

Ik zou zeggen: kijk hoe officiële api's van het framework dat je gebruikt het doen. Dan hou je het lekker consistent. Ik vind dat er ook niet zozeer een onderscheid "per layer" of "per feature" is, het onderscheid is meer "per whatever supposed to be together". Je wil per slot van rekening al die honderden keren dat je door die tree zit te klikken meteen bij de juiste package uitkomen.

[Standeman]

Als ik kijk naar frameworks zoals JSF / Spring / Hibernate (welke kant we zeer waarschijnlijk op gaan) zie ik dat alles per feature is ingedeeld. Later wijzigingen / RFC's zullen toch vaak erg domein georienteerd zijn en dan lijkt het me persoonlijk makkelijk dat je dan zo weinig mogelijk packages raakt.

[Avalaxy]

Per layer lijkt mij het meest logische. Voor alle features heb je bv. een dependency injection container nodig; waar stop je die dan? In alle assemblies? Waar stop je alle generieke interfaces voor bv repositories? Bij welke feature horen die? Ga je dan ook de views die bij die features horen in de desbetreffende assemblies zetten of komen die wél allemaal bij elkaar in een UI assembly? Hoe bepaal je bij welke feature iets hoort? Stel dat je een gebruiker een mailtje wilt sturen als er een reactie is op z'n post, moet dat dan bij de User-feature, de Reply-feature, of iets anders?

[Standeman]

Avalaxy schreef op maandag 20 januari 2014 @ 15:05:
Per layer lijkt mij het meest logische. Voor alle features heb je bv. een dependency injection container nodig; waar stop je die dan? In alle assemblies? Waar stop je alle generieke interfaces voor bv repositories? Bij welke feature horen die? Ga je dan ook de views die bij die features horen in de desbetreffende assemblies zetten of komen die wél allemaal bij elkaar in een UI assembly? Hoe bepaal je bij welke feature iets hoort? Stel dat je een gebruiker een mailtje wilt sturen als er een reactie is op z'n post, moet dat dan bij de User-feature, de Reply-feature, of iets anders?

Andersom zit je imo met hetzelfde probleem. In welke layer horen utility classes? En andere cross-cutting concerns zoals auditing en logging?

[Hydra]

Standeman schreef op maandag 20 januari 2014 @ 15:52:
Andersom zit je imo met hetzelfde probleem. In welke layer horen utility classes? En andere cross-cutting concerns zoals auditing en logging?

Daarom mijn reactie: een gezonden mix

[HMS]

Globaal zou ik zeggen dat je het per feature doet (oftewel verticale slices van je applicatie). Natuurlijk zul je een (aantal) generieke onderste layer(s) krijgen, waar je de overige pijlers op kan neerzetten.

Voorbeelden hiervan zijn: persistence, logging, messaging, dependency injection (IoC), etc.

Deze serie blogposts kan je misschien aan het denken zetten: http://lostechies.com/jim...-diet-posts-and-commands/

Avalaxy schreef op maandag 20 januari 2014 @ 15:05:
Per layer lijkt mij het meest logische. Voor alle features heb je bv. een dependency injection container nodig; waar stop je die dan? In alle assemblies? Waar stop je alle generieke interfaces voor bv repositories? Bij welke feature horen die?

Per layer werkt in mijn ervaring helemaal niet fijn, heel vaak zit je meer in een feature te werken en dan heeft het onderverdelen in verschillende lagen eerder een contraproductieve werking omdat je constant moet bepalen waar iets hoort. Ook ben je heel vaak niet laag per laag bezig, maar werk je top-down (ik in ieder geval wel).

Die zaken die jij noemt horen in de 'infrastructure' feature, net zoals wel meer code die je applicatie ondersteund. Daarnaast kan je d.m.v. DI ook werken met interfaces en dan vanuit je main project bepalen welke at runtime ingeladen wordt, eventuele decorators voor logging en zo kunnen dan ook via je DI container toegepast worden.

Avalaxy schreef op maandag 20 januari 2014 @ 15:05:
Ga je dan ook de views die bij die features horen in de desbetreffende assemblies zetten of komen die wél allemaal bij elkaar in een UI assembly?

Ja, ik heb meestal een folder structuur die er zo uit ziet (met NancyFX):

code:

/{Feature}/View.cshtml
/{Feature}/{Feature}Module.cs
/{Feature}/...

Zo heb je alles wat je van een feature nodig hebt vlak bij elkaar staan, dit verduidelijkt heel erg wat bij elkaar hoort. Als je horizontale slices pakt dan wordt het vaak ondoorzichtelijk wat nu precies door wie gereferenced wordt en wanneer. De dependency graph van groeperen per feature is een stuk overzichtelijker.

Avalaxy schreef op maandag 20 januari 2014 @ 15:05:
Hoe bepaal je bij welke feature iets hoort? Stel dat je een gebruiker een mailtje wilt sturen als er een reactie is op z'n post, moet dat dan bij de User-feature, de Reply-feature, of iets anders?

Dan moet je gaan kijken of je je wel aan de SOLID principles houdt, met name de Single Responsibility Principle. 'Een mail sturen bij een reactie op zijn post' lijkt mij iets wat uitstekend in een event handler kan gebeuren, oftewel dit zou je vrij arbitrair onder kunnen brengen. Eventueel heb je een apart project waar dit in hoort, dat bepaal je helemaal zelf.

Standeman schreef op maandag 20 januari 2014 @ 15:52:
[...]

Andersom zit je imo met hetzelfde probleem. In welke layer horen utility classes? En andere cross-cutting concerns zoals auditing en logging?

Die gaan zeer waarschijnlijk in je infrastructure, waar moet je anders cross-cutting concerns neer zetten ?

[ Voor 6% gewijzigd door HMS op 20-01-2014 17:30 ]

[Styxxy]

Standeman schreef op maandag 20 januari 2014 @ 15:52:
[...]

Andersom zit je imo met hetzelfde probleem. In welke layer horen utility classes? En andere cross-cutting concerns zoals auditing en logging?

Wij hebben daar een shared "layer" (packages / assemblies) voor.