SAP 3 - Package Design
Leerdoel:
Architectuur-ontwerpprincipes kunnen uitleggen en toepassen op doel en code niveau.
- Wat is package design?
- Welke guideline helpen daarbij?
De basisprincipes beschrijven toepassen van software architecture reconstruction.
Package Design
The goal is to create a robust physical package design.
Probleem:
Als package X veel verantwoordelijkheden krijgt van het development team is het niet handig als X
onstabiel is (veel nieuwe versies krijgt), omdat het alles wat afhankelijk is van X steeds opnieuw
gesynchroniseerd moet worden.
Oplossing:
Design de organisatie van de code zo dat dit niet hoeft te gebeuren en gebruik hierbij de
guidelines.
Package Organization Guideline 1
“Package functionality into cohesive vertical and horizontal slices (modules)”
Groepeer klassen en interfaces wanneer ze overeenkomen in deze gebieden:
- Ze werken naar hetzelfde doel toe
- Ze hebben dezelfde samenwerkingen, beleid en functie
Package Organization Guidelines 2 & 3
Basis strategie: vermijd dat veel componenten afhangen van onstabiele packages
“Package by work and by clusters of unstable classes.”
“Most responsible (depended-on) are most stable.”
com.foo.nextgen.
ui.swing Less Stable:
-more dependent
-concrete, detailed
com.foo.nextgen.
domain.sales
com.foo.nextgen.
domain.payments
com.foo.nextgen. More Stable:
domain.posruleengine -less dependent
-concrete, detailed code is stabilized
com.foo.util due to refinement or mandate.
-abstract classes &
interfaces & facades
The more depended-on packages should be the most stable,
because when they do change, they could have the largest
impact
Jet Wardenier 15/12
Leerdoel:
Architectuur-ontwerpprincipes kunnen uitleggen en toepassen op doel en code niveau.
- Wat is package design?
- Welke guideline helpen daarbij?
De basisprincipes beschrijven toepassen van software architecture reconstruction.
Package Design
The goal is to create a robust physical package design.
Probleem:
Als package X veel verantwoordelijkheden krijgt van het development team is het niet handig als X
onstabiel is (veel nieuwe versies krijgt), omdat het alles wat afhankelijk is van X steeds opnieuw
gesynchroniseerd moet worden.
Oplossing:
Design de organisatie van de code zo dat dit niet hoeft te gebeuren en gebruik hierbij de
guidelines.
Package Organization Guideline 1
“Package functionality into cohesive vertical and horizontal slices (modules)”
Groepeer klassen en interfaces wanneer ze overeenkomen in deze gebieden:
- Ze werken naar hetzelfde doel toe
- Ze hebben dezelfde samenwerkingen, beleid en functie
Package Organization Guidelines 2 & 3
Basis strategie: vermijd dat veel componenten afhangen van onstabiele packages
“Package by work and by clusters of unstable classes.”
“Most responsible (depended-on) are most stable.”
com.foo.nextgen.
ui.swing Less Stable:
-more dependent
-concrete, detailed
com.foo.nextgen.
domain.sales
com.foo.nextgen.
domain.payments
com.foo.nextgen. More Stable:
domain.posruleengine -less dependent
-concrete, detailed code is stabilized
com.foo.util due to refinement or mandate.
-abstract classes &
interfaces & facades
The more depended-on packages should be the most stable,
because when they do change, they could have the largest
impact
Jet Wardenier 15/12
