I'm sure every developer wants to be able to change code with confidence and without fear. Readable and self-explanatory code is one aspect of that. Too much coupling is another major source of problems that prevent you from changing one part of the system without causing side-effects. In this talk, I'd like you to show you common sources of unnecessary coupling and offer you options to help prevent and/or break those. I'll talk about how principles like Don't Repeat Yourself and Dependency Injection can be a double-edge sword, how to detect too unnecessary dependencies and how to use the Dependency Inversion Principle to unravel some of those. And yes, I will also talk about controlling dependencies on the package level.

1. at the architecture, package and code level
Getting a grip on your dependencies
Dennis Doomen
@ddoomen | Principal Consultant | The Continuous Improver | Aviva Solutions

2. About Me
Hands-on architect in the .NET space with 26 years of experience on
an everlasting quest for knowledge to build the right software the right
way at the right time
@ddoomen | The Continuous Improver

4. The problem of coupling and cohesion
Dennis Doomen | @ddoomen | The Continuous Improver

5. How do you prevent too
much coupling?

6. We are taught to increase
cohesion and decrease coupling
using abstractions…

7. …but that often leads to too many
abstractions

8. And how do you increase
cohesion?

9. By applying DRY
(Don’t Repeat Yourself)

10. But DRY creates more coupling

11. Then what is the solution?

12. Understand the internal
boundaries!

13. Controlling dependencies on the architecture level
#avivasolutions

14. Adopt an architecture
style that embraces the
DIP
Order Processing
IStoreOrders<T>
+ Query<T>();
+ Add<T>();
+ Delete<T>();
NHibernate
Repository
Order Processing
IStoreOrders
+ GetIncompleteOrders(minValue);
+ StoreOrder();
+ CompleteOrder();
OrderRepository
VS

15. Onion
Architecture Domain Model

16. Hexagonal
Architecture
(a.k.a. Ports
& Adapters)
Domain
Application
Primary Port
Primary Port
Secondary
Port
Secondary
Port
Web
Adapter
API
Adapter
Database
Adapter
Adapter
Dependencies Dependencies

17. Clean
Architecture Entities

18. Organize by functionalities / capabilities

19. Apply DRY within those “boundaries”
Duplicated
Service 1
Duplicated
Service 1
Duplicated
Service 2
Duplicated
Service 2
Duplicated
Service 1
Centralized
Service 3
Extension
Methods
Extension
Methods
Extension
Methods
Extension
Methods
Helpers Helpers Helpers Helpers

20. Service Service
Service Service
Service
Centralized
Service
Align your test scope with those “boundaries”

21. Controlling dependencies on the package level
Dennis Doomen | @ddoomen | The Continuous Improver

22. Main Package
Application
Bunch of blocks that
can be used directly
Uses composition
over inheritance
Convenience
blocks that don’t
hide the magic
Shared Package
Contract
Contract
Only depend on
more abstract
packages…
Stable Package
…or depend on more
stable packages
Auxiliary Package
Blocks that are not
used together do not
belong together
Optional
Dependency
Dependency
Package
Consumers should
not be faced with
optional
dependencies
No cyclic
dependencies
Principles of successful package management

23. Controlling dependencies on the code level
Dennis Doomen | @ddoomen | The Continuous Improver

24. Avoid technical folders and organize code by
functionalities / capabilities
Functional
Folders
“Unit” of (integration)
testing
DRY within boundaries
Can be used to
clarify “public”
parts
Only unit tested
for specific
reasons
Role-based
interface name

25. Treat adjacent folders as
separate boundaries

26. Use the Tell, Don’t
Ask principle

27. Use the Law of Demeter to
detect unnecessary coupling

28. Encapsulate primitive
types and collections

29. DI is great, but avoid a global container
Local DI
container
Local DI
container
Local DI
container
No DI container
needed
No DI container
needed.

30. It’s fine to inject concrete
classes inside boundaries

31. Dealing with legacy code
A potential strategy
#avivasolutions

32. Create a safety net
(e.g. Characterizations Tests)

33. Find existing seams and
decouple them
1. Install a tool to visualize code
2. Identify modules or functional slices
3. Identify types that are supposed to be used together
4. Identify types are designed to be reusable
5. Find IoC registrations and verify 2 and 3
6. Assume code in adjacent folders to be independent

34. Use your learnings to visualize the target architecture

35. Select a candidate to untangle
first
Application
Legacy
Entangled
Capability

36. Start to untangle
1. Move code to functional folders
2. Apply code-level guidelines
3. Use DIP adapters
4. Duplicate code that isn’t supposed to be
reused
5. Duplicate code that is used in multiple
boundaries
6. Considering moving to local IoC
containers.
IStoreOrders<T>
+ Query<T>();
+ Add<T>();
+ Delete<T>();
NHibernate
Repository
Order Processing
IStoreOrders
+ GetIncompleteOrders(minValue);
+ StoreOrder();
+ CompleteOrder();
Adapter

37. Application
Legacy Extracted
Capability
Another
Entangled
Capability
Rinse and
repeat.

38. Q&A
(the best one wins a 1-year license for JetBrains Rider)
…ping me at @ddoomen
…email me at dennis.doomen@avivasolutions.nl