34 lines
3.6 KiB
Markdown
34 lines
3.6 KiB
Markdown
Coupling = measurement of dependencies
|
||
|
||
- if x depends on y, there is coupling between them
|
||
- Afferent coupling (Ca) - who depends on me
|
||
- Efferent coupling (Ce) - on what do I depend
|
||
- If x depends on y:
|
||
-
|
||
- x is efferently coupled to y
|
||
- y is afferently coupled to x
|
||
|
||
How much coupling is too much? How much coupling is necessary for a class to be useful, but not too high to make it tightly coupled? Certain low-level frameworks or classes we might expect to have a high coupling. For example, logging we would expect to be connected to a high number of other classes. In fact, a low coupling level for a coupling framework might signal problems (not enough logging going on, etc). Efferent coupling is really the bigger issue. A large set of changes can cause problems in the depending class. If A calls one method on B, is it's coupling the same as C which calls three methods on D? Probably not. D has one afferent coupling to C, but C has three efferent couplings to D. Coupling that you can't see
|
||
Two components that depend on one DB are coupled together. **Loose coupling at the systems level**
|
||
- minimize both types of coupling
|
||
- zero coupling isn't really possible Coupling Aspect #1: platform
|
||
Also known as interoperability. 1 of 4 tenets of service orientation: Share contract and schema, not class or type _Solutions_
|
||
Text-based representation on the wire (XML/JSON)--with or without schema.
|
||
Use standards based transfer protocol like http (or smtp, udp, etc). Coupling Aspect #2: temporal
|
||
Synchronous calls. Caller has a high degree of coupling to callee. _Solutions_
|
||
Canonical example: querying a system. There isn't much to do (for the client) until the data comes back. Caching can be used to reduce temporal coupling. Which side should cache be on? Providing or asking side? If you put it on the asking side, then at least you know that you are using a stale copy of data. This can reveal to business stakeholders where data can be stale. This, in turn, then can reveal where you proper service boundaries should be to meet business requirements. Pub/sub helps us solve temporal coupling.
|
||
- Subscriber must be able to make decisions based on somewhat stale data
|
||
- Requires a strong division of responsibility between publishers and subscribers
|
||
- Only one logical publisher should be able to publish a given kind of event Designing events: nothing everything should be modeled as an event. Bad: "SaveCustomerRequested".
|
||
Good examples: "CustomerSaved", "OrderAccepted". It's a fact--already done. Subscriber shouldn't be able to validate it. Include validity period in events so that subscribers know how long to use it. ProductPriceUpdates { Price: $5, ValidTo: 1/1/2015 } Your assumption should be that the way you first divided up your services is actually wrong. _Temporal coupling goes hand in hand with business consistency._ Coupling Aspect #3: spatial
|
||
Topology of IP addresses, DNS and machines. _Solutions_
|
||
Application level code should not need to know whehre cooperating services are on the network.
|
||
Delete communications to lower layer, the service agent pattern.
|
||
How does the agent know which destination to send the message to. Load balancing - clients talking to servers through load balancer. Routing is first logical, then physical. Prefer many strongly-typed messages (clearly communicating intent) over parsing message intent from the content of the message. **Summary**
|
||
Loose coupling is more than just a slogan. Coupling has 5 dimensions:
|
||
|
||
1. Platform
|
||
2. Temporal
|
||
3. Spatial
|
||
4. Efferent
|
||
5. Afferent |