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.
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?
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)
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
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
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
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?