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.
Adobe Marketo Engage Deep Dives: Using Webhooks to Transfer Data
Getting a grip on your code dependencies
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
3.
4. The problem of coupling and cohesion
Dennis Doomen | @ddoomen | The Continuous Improver
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
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
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
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
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