core (entiteter, värdeobjekt, interface till repositories, factories, services)
data (repositories, factories, mappningsklasser)
services (services)
view (command services, vymodeller, vyer)
Gissar command services är ungefär samma sak som det du kallar
action-klasser. Parallellt har vi även system-core, system-data och
system-view (system services har inte behövts).
Vi diskuterade om services skulle ligga ihop med data eller ej, och om
factories skulle vara i core eller ej, men det blev till slut som ovan
utan några tyngre argument för det ena eller andra.
Tanken var att core skulle vara helt oberoende av lagringsteknik, i
praktiken fick vi frångå det eftersom vi skickar med
hibernatesessionen i många metodanrop (det hade ju förstås kunnat
kapslas in men vi tyckte inte det var värt det).
Jag hade velat se en uppdelning i moduler, tyvärr hade vi mycket lite
tid avsatt för modellering och jobbar i ett fastprisprojekt så hela
domänen hamnade i samma modul. Men på det hela taget fungerar det rätt
bra.
Kan väl också säga att vårt system nog inte kvalificerar som ddd, vi
har lånat arkitekturen därifrån, projektet var en migrering av två
befintliga VB-system till .Net, det ena en tvåskiktad, tidig
klient-server lösning och det andra ett från slutet av VB/COM+ eran,
skikat och rätt prydlig OO för att vara VB.
> --
> Det här meddelandet skickas till dig eftersom du prenumererar på gruppen DDD Sverige i Google Groups.
> Om du vill göra ett inlägg i den här gruppen skickar du e-post till dddsv...@googlegroups.com.
> Om du vill sluta prenumerera på den här gruppen skickar du e-post till dddsverige+...@googlegroups.com.
> För fler alternativ, besök gruppen på http://groups.google.com/group/dddsverige?hl=sv.
>
>
On 2011-02-18 01.02, thomasj wrote:
> Jag skulle vilja h�ra era �sikter ang�ende modularisering, och i
> sammanhanget avser modul det som resulterar i en jarfil vid
> paketering.
F�r mig handlar modularisering mer om logisk struktur, dvs
dependency-m�ssigt. Hur jag sedan v�ljer att paketera �r en helt annan
sak, och har mer med vilka artefakter som "makes sense" f�r deployment.
Detta blir extra tydligt om man anv�nder Qi4j (s� som vi g�r) eftersom
det d�r finns explicit st�d f�r b�de lager och moduler. I mitt nuvarande
projekt har vi 7 lager (f�r server-sidan):
* Configuration
* Infrastructure (=DB, Lucene, etc.)
* Domain
* Context (=usecases)
* Application services
* Web (=Restlet)
* Management (=JMX)
Dependencies mellan dessa lager �r:
Management -> Application, Domain, Infrastructure, Configuration
Web -> Application, Context, Domain, Infrastructure
Application -> Domain, Infrastructure, Configuration
Context -> Domain, Application, Infrastructure
Domain -> Infrastructure
Infrastructure -> Configuration
Inom Domain finns det sedan moduler f�r de olika delarna i
dom�nmodellen. Alltihop �r just numera paketerat som en WAR-fil, dvs
ingen paketering i separata jar-filer, trots att vi har allts� har en
hel del struktur internt.
Vi har sedan d�rut�ver en separat jar med DTO-klasser som delas mellan
server och klient. DTO-klasserna anv�nds fr�mst av Web/Context lagren,
som representerar v�ra usecase.
/Rickard
Hejsan!
On 2011-02-18 01.02, thomasj wrote:
Jag skulle vilja höra era åsikter angående modularisering, och i
sammanhanget avser modul det som resulterar i en jarfil vid
paketering.
För mig handlar modularisering mer om logisk struktur, dvs dependency-mässigt. Hur jag sedan väljer att paketera är en helt annan sak, och har mer med vilka artefakter som "makes sense" för deployment.
Detta blir extra tydligt om man använder Qi4j (så som vi gör) eftersom det där finns explicit stöd för både lager och moduler. I mitt nuvarande projekt har vi 7 lager (för server-sidan):
* Configuration
* Infrastructure (=DB, Lucene, etc.)
* Domain
* Context (=usecases)
* Application services
* Web (=Restlet)
* Management (=JMX)
Dependencies mellan dessa lager är:
Management -> Application, Domain, Infrastructure, Configuration
Web -> Application, Context, Domain, Infrastructure
Application -> Domain, Infrastructure, Configuration
Context -> Domain, Application, Infrastructure
Domain -> Infrastructure
Infrastructure -> Configuration
Inom Domain finns det sedan moduler för de olika delarna i domänmodellen. Alltihop är just numera paketerat som en WAR-fil, dvs ingen paketering i separata jar-filer, trots att vi har alltså har en hel del struktur internt.
Vi har sedan därutöver en separat jar med DTO-klasser som delas mellan server och klient. DTO-klasserna används främst av Web/Context lagren, som representerar våra usecase.
/Rickard
Om du använder Qi4j och definierar lager/moduler så finns verktyg för
att visualisera den struktur och dependencies som du satt upp, med
export till PDF. Dvs din kod blir master för arkitekturen, snarare än
att det definieras i ett Word-dokument någonstans (aka Worditecture).
>
> Rickard, det var förresten jag som överöste dig med Sitevision-frågor för ett par år sedan då du jobbade på Senselogic och jag på WM-data i Helsingborg.
Ah, tyckte väl att namnet kändes bekant :-)
/Rickard