Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)
Download as PPTX, PDF2 likes1,188 views
The document discusses the need for modular software architecture and design. It outlines some common problems that arise when software lacks proper architecture, such as becoming difficult to maintain and test. The presentation then covers principles of modular design like reusability and encapsulation. It demonstrates an example application of the Hexagonal architecture pattern with layers for the domain, application, and infrastructure. Benefits of modular design include increased maintainability and reduced technical debt. Challenges include shifting mindsets and requiring full-stack development teams.
Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)
- 1. Bojan Veljanovski Chief Technology Officer @ HASELT @bojanv91 Modular Software Architecture & Design 1
- 3. Outline • Why we need to apply architecture & design? • Path to modularity – Layers, Use cases, Hexagons • DEMO • Benefits and tradeoffs • Questions & Discussions 3
- 4. Goal: Make apps easier to understand. 4
- 5. Perfect software does not exist! Only good enough. 5
- 6. But, how good is “good enough”? 6
- 7. • Imprecise, ambiguous or unclear requirements • Implementing features with no design – Tight coupling – Cyclic dependencies – Not well separated concerns • Ignoring software entropy – System complexity increases with code modifications. 7 What makes Software bad?
- 8. 8 What problems can you spot?
- 9. • Code becomes hard to maintain • Simple changes become complex changes • Feature/Change estimates increase drastically • Fixed bugs start to re-appear • Developers start to freak out and get demotivated • Testing becomes hard and expensive • Projects fail or forced to be rewritten 9 Consequences
- 10. • Increase Maintainability – reduction of technical debt • Decrease Technical Debt – debt payed in time and frustration for bad decisions 10 The need for arc. & design
- 11. • Maintainability – Changes in one area of an app does not affect other – Adding new features does not need large code-base changes (new features -> new code) – Adding new ways to interact with the app does not need changes in application or domain logic – Testing is straightforward • Technical Debt – Number of team hours to re-factor the codebase to a state that the team would be comfortable and productive to work with 11 The need for arc. & design (2)
- 12. 12 Everything is interrelated (beware of context!)
- 13. Modular-based architecture styles 13 • Application decomposed into reusable logical modules and components that expose well-defined communication interfaces. • Aligning modular structure around domain concepts • Organize responsibility around business features instead of technical functions
- 14. Key principles 14 • Reusable • Replaceable • Not context specific • Extensible • Encapsulated • Independent
- 15. Hexagonal Architecture • Allow an application to be equally driven by users, programs, automated test or batch scripts, and to be developed and tested in isolation from its eventual run- time devices and databases. • http://alistair.cockburn.us/Hexagonal+architecture 15
- 16. 16
- 17. 17
- 18. 18
- 19. Structure • Domain – Entities, Aggregates – Events – Repositories • Application – Actions (Commands and Queries) – Handlers • Infrastructure – Adapters for database, filesystem, message buses, http connections, action runners • Delivery – Web UIs, HTTP API endpoints, Console app, Bots, Test framework 19
- 20. 20 • Ports – Allow for communication to happen • Adapters – Translate messages from the outside world Communication between layers
- 21. “Loudest” design patterns • Domain Layer – Domain modeling with DDD principles • Application Layer – CQRS components – Dependency Injection – Decorator • Infrastructure – Composite root – Mediator • SOLID principles apply everywhere 21
- 25. 25 Horizontal vs. Vertical structure
- 26. 26
- 27. Action / Feature • Intention revealing • One responsibility • Says WHAT, not HOW • Application service component – Command • Tells entities what to do – Query • Retrieves data from storage • e.g.: Register user, Buy ticket, Filter active customers etc. 27
- 28. Action object is defined with • Communication Boundary – Request – Response • Coordination Logic – Validator – Handler 28
- 30. Common Handler execution steps 1. Audit log 2. Validate request 3. Begin transaction 4. Load Aggregate 5. Operate to Aggregate 6. Store Aggregate 7. Dispatch raised domain events / notifications 8. Commit transaction 30
- 31. DEMO 31
- 32. 32 How to reuse modules? • Separate Assembly (Shared Assembly) • NuGet package • Distributed service (Microservice)
- 33. 33 Natural evolution towards SOA / Microservices
- 34. Benefits • Increased maintainability • Developing, testing and tuning modules independently • Making applications more flexible and extensible • Easier to test in isolation • Easily re-use modules in other projects • Modules can evolve independently – By functional requirements – By non-functional requirements – By team organization size and style • Things are much easier to find – Thus apps are easier to understand 34
- 35. Challenges and tradeoffs • Mind-shift from the mainstream .NET development • Need of a full-stack development team • Larger number of files and classes 35
- 36. Complete the evaluation and earn the chance to win prizes in the closing raffle http://eval.codecamp.mk 36 Questions?
- 37. Thank you 37