Successfully reported this slideshow.
Your SlideShare is downloading. ×

Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Loading in …3
×

Check these out next

1 of 37 Ad

Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)

Download to read offline

In this talk I want to share with you an alternative way to develop .NET applications in a more modular way by embracing emergent design techniques. The main idea is to decompose your application into small and reusable modules, in order to achieve high maintainability, low technical debt and prevent the ‘Big Ball of Mud’ creeping in. But how to succeed with this?

Come to my session and you’ll gain a whole new way of thinking about programming, reasoning and designing great software.

In this talk I want to share with you an alternative way to develop .NET applications in a more modular way by embracing emergent design techniques. The main idea is to decompose your application into small and reusable modules, in order to achieve high maintainability, low technical debt and prevent the ‘Big Ball of Mud’ creeping in. But how to succeed with this?

Come to my session and you’ll gain a whole new way of thinking about programming, reasoning and designing great software.

Advertisement
Advertisement

More Related Content

Slideshows for you (20)

Viewers also liked (20)

Advertisement

Similar to Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016) (20)

Advertisement

Recently uploaded (20)

Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)

  1. 1. Bojan Veljanovski Chief Technology Officer @ HASELT @bojanv91 Modular Software Architecture & Design 1
  2. 2. 2 General Sponsors Platinum Sponsors Silver Sponsors Gold Sponsors Bronze Sponsors
  3. 3. Outline • Why we need to apply architecture & design? • Path to modularity – Layers, Use cases, Hexagons • DEMO • Benefits and tradeoffs • Questions & Discussions 3
  4. 4. Goal: Make apps easier to understand. 4
  5. 5. Perfect software does not exist! Only good enough. 5
  6. 6. But, how good is “good enough”? 6
  7. 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. 8 What problems can you spot?
  9. 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. 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. 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. 12 Everything is interrelated (beware of context!)
  13. 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. 14. Key principles 14 • Reusable • Replaceable • Not context specific • Extensible • Encapsulated • Independent
  15. 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. 16
  17. 17. 17
  18. 18. 18
  19. 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. 20 • Ports – Allow for communication to happen • Adapters – Translate messages from the outside world Communication between layers
  21. 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
  22. 22. Implementation… 22
  23. 23. 23 Organization by Technical Functions
  24. 24. 24 Organization by Business Features
  25. 25. 25 Horizontal vs. Vertical structure
  26. 26. 26
  27. 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. 28. Action object is defined with • Communication Boundary – Request – Response • Coordination Logic – Validator – Handler 28
  29. 29. 29 Application interaction flow
  30. 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. 31. DEMO 31
  32. 32. 32 How to reuse modules? • Separate Assembly (Shared Assembly) • NuGet package • Distributed service (Microservice)
  33. 33. 33 Natural evolution towards SOA / Microservices
  34. 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. 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. 36. Complete the evaluation and earn the chance to win prizes in the closing raffle http://eval.codecamp.mk 36 Questions?
  37. 37. Thank you 37

×