bojan veljanovski - modular software architecture and design (code camp 2016)
TRANSCRIPT
![Page 1: Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)](https://reader037.vdocument.in/reader037/viewer/2022102917/58f36ce51a28ab733d8b45b5/html5/thumbnails/1.jpg)
1
Bojan VeljanovskiChief Technology Officer @ HASELT
@bojanv91
Modular Software Architecture & Design
![Page 2: Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)](https://reader037.vdocument.in/reader037/viewer/2022102917/58f36ce51a28ab733d8b45b5/html5/thumbnails/2.jpg)
2
General SponsorsPlatinum Sponsors
Silver Sponsors
Gold Sponsors
Bronze Sponsors
![Page 3: Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)](https://reader037.vdocument.in/reader037/viewer/2022102917/58f36ce51a28ab733d8b45b5/html5/thumbnails/3.jpg)
3
Outline
• Why we need to apply architecture & design?• Path to modularity– Layers, Use cases, Hexagons
• DEMO• Benefits and tradeoffs • Questions & Discussions
![Page 4: Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)](https://reader037.vdocument.in/reader037/viewer/2022102917/58f36ce51a28ab733d8b45b5/html5/thumbnails/4.jpg)
4
Goal: Make apps easier to understand.
![Page 5: Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)](https://reader037.vdocument.in/reader037/viewer/2022102917/58f36ce51a28ab733d8b45b5/html5/thumbnails/5.jpg)
5
Perfect software does not exist! Only good enough.
![Page 6: Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)](https://reader037.vdocument.in/reader037/viewer/2022102917/58f36ce51a28ab733d8b45b5/html5/thumbnails/6.jpg)
6
But, how good is “good enough”?
![Page 7: Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)](https://reader037.vdocument.in/reader037/viewer/2022102917/58f36ce51a28ab733d8b45b5/html5/thumbnails/7.jpg)
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.
What makes Software bad?
![Page 8: Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)](https://reader037.vdocument.in/reader037/viewer/2022102917/58f36ce51a28ab733d8b45b5/html5/thumbnails/8.jpg)
8
What problems can you spot?
![Page 9: Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)](https://reader037.vdocument.in/reader037/viewer/2022102917/58f36ce51a28ab733d8b45b5/html5/thumbnails/9.jpg)
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
Consequences
![Page 10: Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)](https://reader037.vdocument.in/reader037/viewer/2022102917/58f36ce51a28ab733d8b45b5/html5/thumbnails/10.jpg)
10
• Increase Maintainability– reduction of technical debt
• Decrease Technical Debt– debt payed in time and frustration for bad
decisions
The need for arc. & design
![Page 11: Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)](https://reader037.vdocument.in/reader037/viewer/2022102917/58f36ce51a28ab733d8b45b5/html5/thumbnails/11.jpg)
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
The need for arc. & design (2)
![Page 12: Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)](https://reader037.vdocument.in/reader037/viewer/2022102917/58f36ce51a28ab733d8b45b5/html5/thumbnails/12.jpg)
12
Everything is interrelated(beware of context!)
![Page 13: Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)](https://reader037.vdocument.in/reader037/viewer/2022102917/58f36ce51a28ab733d8b45b5/html5/thumbnails/13.jpg)
13
Modular-based architecture styles
• 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
![Page 14: Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)](https://reader037.vdocument.in/reader037/viewer/2022102917/58f36ce51a28ab733d8b45b5/html5/thumbnails/14.jpg)
14
Key principles• Reusable• Replaceable• Not context specific• Extensible• Encapsulated• Independent
![Page 15: Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)](https://reader037.vdocument.in/reader037/viewer/2022102917/58f36ce51a28ab733d8b45b5/html5/thumbnails/15.jpg)
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
![Page 16: Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)](https://reader037.vdocument.in/reader037/viewer/2022102917/58f36ce51a28ab733d8b45b5/html5/thumbnails/16.jpg)
16
![Page 17: Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)](https://reader037.vdocument.in/reader037/viewer/2022102917/58f36ce51a28ab733d8b45b5/html5/thumbnails/17.jpg)
17
![Page 18: Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)](https://reader037.vdocument.in/reader037/viewer/2022102917/58f36ce51a28ab733d8b45b5/html5/thumbnails/18.jpg)
18
![Page 19: Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)](https://reader037.vdocument.in/reader037/viewer/2022102917/58f36ce51a28ab733d8b45b5/html5/thumbnails/19.jpg)
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
![Page 20: Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)](https://reader037.vdocument.in/reader037/viewer/2022102917/58f36ce51a28ab733d8b45b5/html5/thumbnails/20.jpg)
20
• Ports– Allow for communication to happen
• Adapters– Translate messages from the outside world
Communication between layers
![Page 21: Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)](https://reader037.vdocument.in/reader037/viewer/2022102917/58f36ce51a28ab733d8b45b5/html5/thumbnails/21.jpg)
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
![Page 22: Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)](https://reader037.vdocument.in/reader037/viewer/2022102917/58f36ce51a28ab733d8b45b5/html5/thumbnails/22.jpg)
22
Implementation…
![Page 23: Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)](https://reader037.vdocument.in/reader037/viewer/2022102917/58f36ce51a28ab733d8b45b5/html5/thumbnails/23.jpg)
23
Organization by Technical Functions
![Page 24: Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)](https://reader037.vdocument.in/reader037/viewer/2022102917/58f36ce51a28ab733d8b45b5/html5/thumbnails/24.jpg)
24
Organization by Business Features
![Page 25: Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)](https://reader037.vdocument.in/reader037/viewer/2022102917/58f36ce51a28ab733d8b45b5/html5/thumbnails/25.jpg)
25
Horizontal vs. Vertical structure
![Page 26: Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)](https://reader037.vdocument.in/reader037/viewer/2022102917/58f36ce51a28ab733d8b45b5/html5/thumbnails/26.jpg)
26
![Page 27: Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)](https://reader037.vdocument.in/reader037/viewer/2022102917/58f36ce51a28ab733d8b45b5/html5/thumbnails/27.jpg)
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.
![Page 28: Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)](https://reader037.vdocument.in/reader037/viewer/2022102917/58f36ce51a28ab733d8b45b5/html5/thumbnails/28.jpg)
28
Action object is defined with• Communication Boundary– Request– Response
• Coordination Logic– Validator– Handler
![Page 29: Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)](https://reader037.vdocument.in/reader037/viewer/2022102917/58f36ce51a28ab733d8b45b5/html5/thumbnails/29.jpg)
29
Application interaction flow
![Page 30: Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)](https://reader037.vdocument.in/reader037/viewer/2022102917/58f36ce51a28ab733d8b45b5/html5/thumbnails/30.jpg)
30
Common Handler execution steps1. Audit log2. Validate request3. Begin transaction
4. Load Aggregate 5. Operate to Aggregate6. Store Aggregate
7. Dispatch raised domain events / notifications8. Commit transaction
![Page 31: Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)](https://reader037.vdocument.in/reader037/viewer/2022102917/58f36ce51a28ab733d8b45b5/html5/thumbnails/31.jpg)
31
DEMO
![Page 32: Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)](https://reader037.vdocument.in/reader037/viewer/2022102917/58f36ce51a28ab733d8b45b5/html5/thumbnails/32.jpg)
32
How to reuse modules?• Separate Assembly (Shared Assembly)• NuGet package• Distributed service (Microservice)
![Page 33: Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)](https://reader037.vdocument.in/reader037/viewer/2022102917/58f36ce51a28ab733d8b45b5/html5/thumbnails/33.jpg)
33
Natural evolution towards SOA / Microservices
![Page 34: Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)](https://reader037.vdocument.in/reader037/viewer/2022102917/58f36ce51a28ab733d8b45b5/html5/thumbnails/34.jpg)
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
![Page 35: Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)](https://reader037.vdocument.in/reader037/viewer/2022102917/58f36ce51a28ab733d8b45b5/html5/thumbnails/35.jpg)
35
Challenges and tradeoffs• Mind-shift from the mainstream .NET development• Need of a full-stack development team• Larger number of files and classes
![Page 36: Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)](https://reader037.vdocument.in/reader037/viewer/2022102917/58f36ce51a28ab733d8b45b5/html5/thumbnails/36.jpg)
36
Complete the evaluation and earn the chance to win prizes in the closing rafflehttp://eval.codecamp.mk
Questions?
![Page 37: Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)](https://reader037.vdocument.in/reader037/viewer/2022102917/58f36ce51a28ab733d8b45b5/html5/thumbnails/37.jpg)
37
Thank you