Moduler
thomasj
Hemkommen från JFokus med ny energi och inspiration! Tack till er som
gjorde konferensen möjlig.
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 en tid sedan bröt jag ur paket och klasser som inte
hade med domänfunktion att göra till en separat modul, och kvar i den
"gamla" modulen blev således paket och klasser som fokuserar på den
funktionella domänen. Det var ju bra, tydligare och mer fokuserat. Men
vad anser ni, ska jag ta det ett steg längre, att bryta ut så att
entiteter och värdeobjekt hamnar i en modul, och att home-/service-/
query(repository)/manager-klasser och allt vad de heter hamnar i en
separat modul?
Nuvarande struktur:
system-core (systemfunktionalitet, auditing, behörigheter, fix- och
jobbhanterare).
core (entiteter, home-klasser, repositories, services, mm för core
domänen). Notera att det är inte Evans definition på core detta är.
subledger (entiteter, home-klasser, repositories, services, mm för
subledger domänen)
core-web (action-klasser)
subledger-web (action-klasser)
Alternativ struktur:
system-core (systemfunktionalitet, auditing, behörigheter, fix- och
jobbhanterare).
core-domain (entiteter, värdeobjekt)
core(repositories,home-klasser, services, mm för core domänen).
subledger-domain (entiteter, värdeobjekt)
subledger (repositories, services, mm för subledger domänen)
core-web (action-klasser)
subledger-web (action-klasser)
Med vänliga hälsningar,
Thomas
Fredrik Klintebäck
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.
>
>
Rickard Öberg
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
Thomas Jonsson
Tack för er syn på saken Fredrik och Rickard.
"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."
Jo, det är ju klart, jag ville mest tydliggöra att det var inte paketmodularisering jag syftade på. Våra moduler har hittills arbetats fram med följande syften:
1) Att visuellt lätt kunna identifiera olika delsystem i applikationen
2) Felaktig användning av klasser. Action-klasser användes i Home-klasser, t.ex.
3) Delning av artifacter inom organisationen/produkter.
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.
/Thomas
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
Rickard Öberg
Jonsson<jonsson...@gmail.com>:
> Jo, det är ju klart, jag ville mest tydliggöra att det var inte paketmodularisering jag syftade på. Våra moduler har hittills arbetats fram med följande syften:
> 1) Att visuellt lätt kunna identifiera olika delsystem i applikationen
> 2) Felaktig användning av klasser. Action-klasser användes i Home-klasser, t.ex.
> 3) Delning av artifacter inom organisationen/
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