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