CONSUMER BEHAVIOR Assistant professor Bojan Georgievski PhD 1.
Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)
-
Upload
bojan-veljanovski -
Category
Software
-
view
219 -
download
0
Transcript of Bojan Veljanovski - Modular Software Architecture and Design (Code Camp 2016)
1
Bojan VeljanovskiChief Technology Officer @ HASELT
@bojanv91
Modular Software Architecture & Design
2
General SponsorsPlatinum Sponsors
Silver Sponsors
Gold Sponsors
Bronze Sponsors
3
Outline
• Why we need to apply architecture & design?• Path to modularity– Layers, Use cases, Hexagons
• DEMO• Benefits and tradeoffs • Questions & Discussions
4
Goal: Make apps easier to understand.
5
Perfect software does not exist! Only good enough.
6
But, how good is “good enough”?
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?
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
Consequences
10
• Increase Maintainability– reduction of technical debt
• Decrease Technical Debt– debt payed in time and frustration for bad
decisions
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
The need for arc. & design (2)
12
Everything is interrelated(beware of context!)
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
14
Key principles• 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
16
17
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
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
22
Implementation…
23
Organization by Technical Functions
24
Organization by Business Features
25
Horizontal vs. Vertical structure
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.
28
Action object is defined with• Communication Boundary– Request– Response
• Coordination Logic– Validator– Handler
29
Application interaction flow
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
31
DEMO
32
How to reuse modules?• Separate Assembly (Shared Assembly)• NuGet package• Distributed service (Microservice)
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
35
Challenges and tradeoffs• Mind-shift from the mainstream .NET development• Need of a full-stack development team• Larger number of files and classes
36
Complete the evaluation and earn the chance to win prizes in the closing rafflehttp://eval.codecamp.mk
Questions?
37
Thank you