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.

1. Bojan Veljanovski
Chief Technology Officer @ HASELT
@bojanv91
Modular Software
Architecture & Design
1

2. 2
General
Sponsors
Platinum
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
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

22. Implementation…
22

23. 23
Organization by
Technical Functions

24. 24
Organization by
Business Features

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

29. 29
Application interaction flow

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