Download to read offline
Uploaded byDennis Doomen
Using Boundary-Driven Development to beat code complexity
The document discusses boundary-driven development principles, emphasizing the importance of managing dependencies at various levels, including architecture, package, and code. It highlights strategies for increasing cohesion and decreasing coupling through the use of abstractions and proper organizational techniques. Additionally, it offers insights into dealing with legacy code to improve project design and deployability.
More Related Content
Similar to Using Boundary-Driven Development to beat code complexity
More from Dennis Doomen
Using Boundary-Driven Development to beat code complexity
- 1. Boundary-Driven Development Dennis Doomen @ddoomen |Principal Consultant | Microsoft MVP Oredev ‘24
- 2. About Me Coding Architectin the .NET space with 28 years of experience on an everlasting quest for knowledge to build the right software the right way at the right time
- 3. How do youprevent too much coupling?
- 4. Increase cohesion and decreasecoupling using abstractions…
- 5. …but that oftenleads to too many abstractions
- 6. And how doyou increase cohesion?
- 7. By applying DRY (Don’tRepeat Yourself)
- 8. But DRY createsmore coupling
- 9. Then what is thesolution?
- 10.
- 11.
- 12. Adopt an architecture stylethat embraces the DIP Order Processing IStoreOrders<T> + Query<T>(); + Add<T>(); + Delete<T>(); NHibernate Repository Order Processing IStoreOrders + GetIncompleteOrders(minValue); + StoreOrder(); + CompleteOrder(); OrderRepository VS
- 13.
- 14.
- 15.
- 16. Organize by functionalities/ capabilities
- 17. Apply DRY withinthose “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
- 18. Service Service Service Service Service Centralized Service Alignyour test scope with those “boundaries” b o u w e l
- 19.
- 20. Main Package Application Bunch ofblocks 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
- 21.
- 22. Reduce code visibilityRemove unused code
- 23. Avoid technical foldersand 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
- 24. Treat adjacent folders asseparate boundaries
- 25. Use the Tell,Don’t Ask principle
- 26. Use the Lawof Demeter to detect unnecessary coupling
- 27.
- 28. 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.
- 29. It’s fine toinject concrete classes inside boundaries
- 30.
- 31. Inspect the project dependencies,folder names and namespaces
- 32. Use Type DependenciesDiagram in Rider/R#
- 33.
- 34.
- 35. Let AI toolingexplain the code
- 36.
- 37. My typical improvement flow Understand the production environmen t Understand the code base Finddead and unused code Build a safety net Improve deployability Improve code quality Improve code design Improve architecture
- 38. Create a safetynet (e.g. Characterizations Tests)
- 39. Characteristics Test Suite Addcharacteristics tests Application Legacy Code Base Production Backup
- 40. Use Test Containers CharacteristicsTest Suite Application Legacy Code Base Linux Test Container SQL Server
- 41. Find existing seamsand 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
- 42. Use your learningsto visualize the target architecture I t a ll s t a r
- 43. Select a candidateto untangle first Application Legacy Entangled Capability
- 44. 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 shared 5. Duplicate code that is used in multiple boundaries 6. De-duplicate code that is reusable and complicated 7. Considering moving to local IoC containers. IStoreOrders<T> + Query<T>(); + Add<T>(); + Delete<T>(); NHibernate Repository Order Processing IStoreOrders + GetIncompleteOrders(minValue); + StoreOrder(); + CompleteOrder(); Adapter
- 45.
- 46. Find me at twitter:ddoomen mastodon: @ddoomen.mastodon.social bluesky: @ddoomen.bsky.social email: dennis.doomen@avivasolutions.nl slack: fluentassertions.slack.com