[Clarence]

Ursprungligen postat av ConnyWesth

Om du tänker verksamhetsspecifikt (domain-driven-development, DDD) så kan man bygga en uppsättning klasser som följer strukturen på "verksamheten" eller "domänen". Helt utan koppling till HTML över huvud taget.

Sen kopplar man ihop det hela med "tekniska" klasser som lägger på HTML-taggar där det behövs.

Man kan givetvis koppla ihop detta med en rad andra externa ramverk efter tycke och smak.

Det finns dessutom olika skiktningsmodeller:

MVC - Model-View-Controller (Gammal modell som använts i mer än 20 år)

eller

MVVM Model-View-ViewModel (Modernare variant som anpassats till många olika GUI-device). Se http://en.wikipedia.org/wiki/Model_View_ViewModel för mer info.

Det finns en annan paradigm som kallas test-driven-utveckling (TDD) men den har ett grundläggande tankefel, det går nämligen aldrig att "testa" fram bra kvalitet i en applikation. Kvaliteten måste man designa in från början genom att ha järnkoll på arkitekturen och verksamhetens krav, det är inte testerna som är kraven som många TDD förespråkare hävdar.

Jag är som sagt mer anhängare av DDD-paradigmen med arkitekturell design.

Givetvis ska man testa koden utförligt, men det är inte alltid möjligt att testa allt man behöver testa genom automatiska tester, det skulle kosta för mycket att bygga såna automatiska tester, så projektet skulle bli olönsamt. Man behöver en kombination av automatiska testrutiner och manuella för att optimera ekonomin i projekten.

Minst sagt konstig syn på TDD, du borde testa att jobba med det ett par dagar så du får lite bättre koll på det. Dels så går det alldeles utmärkt att tillämpa både DDD och TDD i samma projekt. Precis som TDD passar med i princip alla andra utvecklingsmetoder eller patterns förutom riktigt kass kod. TDD har inget med din design att göra, även om dålig design är svår att testa ordentligt.

Det finns heller ingen pragmatisk TDD-förespråkare som säger att du ska ha 100% code coverage eller för den delen inte använda andra testmetoder.

Med MVVM ska man tänka på att den inte fått så stor spridning ännu. En annan potentiell uppstickare är HMVC. Både är värda en titt om man tycker att MVC-modellen har brister för en speciell applikation (tänk på att många MVC-ramverk i princip låter dig använda HMVC).

[dAEk]

Ursprungligen postat av Clarence

Minst sagt konstig syn på TDD [...]

Så tänkte jag också men så lät jag det sjunka in lite.
Skall man vara strikt skall ju TDD forma koden och det verkar krocka med DDD som jag förstår det. Det kanske är det Conny menar?

Tester kan man såklart ha i DDD också.

[Clarence]

Ursprungligen postat av dAEk

Så tänkte jag också men så lät jag det sjunka in lite.
Skall man vara strikt skall ju TDD forma koden och det verkar krocka med DDD som jag förstår det. Det kanske är det Conny menar?

Tester kan man såklart ha i DDD också.

Håller inte med. Läser du ut TDD som en test driven design så har du gått ifrån dess ursprungliga mening och borde därmed ta tid att förklara vad du menar.

[dAEk]

Ursprungligen postat av Clarence

Håller inte med. Läser du ut TDD som en test driven design så har du gått ifrån dess ursprungliga mening och borde därmed ta tid att förklara vad du menar.

Jag menar inte att man kan strunta i arkitekturen utan mer att man har den i åtanke när man kodar. I TDD utgår man (läs. jag) från testerna, klasserna designas löpande i takt med att beroenden tillkommer; DDD verkar ha vissa förutbestämda klossar som man utgår från. Vet inte om min bild är skev men det är så jag ser på det.

[Clarence]

Ursprungligen postat av dAEk

Jag menar inte att man kan strunta i arkitekturen utan mer att man har den i åtanke när man kodar. I TDD utgår man (läs. jag) från testerna, klasserna designas löpande i takt med att beroenden tillkommer; DDD verkar ha vissa förutbestämda klossar som man utgår från. Vet inte om min bild är skev men det är så jag ser på det.

Såsom jag ser det förändrar det bara vad och hur man testar. Du testar inte states utan beteende. Det finns mycket att läsa om kombinationen TDD DDD - dess svårigheter och best practices. Det finns även en mängd exempel-projekt på github som ger lite hints om man är mer praktiskt lagd.

Dock skulle jag vilja säga att DDD sällan (dvs mer än aldrig men mindre än ofta!) är sunt och TDD alltid är sunt.