Szymon Homa 
Approach to automated 
tests with DDD and 
Hexagonal Architecture as a 
background. 
@s2lomon
Hexagonal Architecture 
Alistair Cockburn, Hexagonal Architecture
Hexagonal Architecture with a little bit of DDD 
Alistair Cockburn, Hexagonal Architecture 
Domain Model
Hexagonal Architecture along with 
Bounded Context 
Alistair Cockburn, Hexagonal Architecture
Hexagonal Architecture 
Alistair Cockburn, Hexagonal Architecture 
Domain Model 
Direction of 
Interactions
Tests of a Model 
Domain Model 
Alistair Cockburn, Hexagonal Architecture 
100% Unit Test (TDD) 
Classic TDD is the best option 
in a vast majority cases 
Test Double can be used only in a case 
of having a pure abstraction 
(like Strategy/Specyfication pattern) 
It’s good to have a Test Fixture
Tests of an Application Layer. 
Domain Model 
Alistair Cockburn, Hexagonal Architecture 
Test Double almost allways when we 
interact with another service, or separated 
functionality 
We should be using Model as it is 
(without Test Double) 
Model can (should) be produced by a same 
Test Fixture 
From time to time we can use Dummy 
instead of an actual implementation.
Tests in an Infrastructure Layer 
Domain Model 
Alistair Cockburn, Hexagonal Architecture 
Integration tests should prevail 
Unit tests should be used only for classes 
that contains logic required to implement 
the actual adapter, like Assembler, 
Query Builder etc. 
Good place for acceptance tests 
"Test Double" can be occasionally used for 
external interfaces
Thanks

Approach to automated tests with ddd and hexagonal architecture as a background

  • 1.
    Szymon Homa Approachto automated tests with DDD and Hexagonal Architecture as a background. @s2lomon
  • 2.
    Hexagonal Architecture AlistairCockburn, Hexagonal Architecture
  • 3.
    Hexagonal Architecture witha little bit of DDD Alistair Cockburn, Hexagonal Architecture Domain Model
  • 4.
    Hexagonal Architecture alongwith Bounded Context Alistair Cockburn, Hexagonal Architecture
  • 5.
    Hexagonal Architecture AlistairCockburn, Hexagonal Architecture Domain Model Direction of Interactions
  • 6.
    Tests of aModel Domain Model Alistair Cockburn, Hexagonal Architecture 100% Unit Test (TDD) Classic TDD is the best option in a vast majority cases Test Double can be used only in a case of having a pure abstraction (like Strategy/Specyfication pattern) It’s good to have a Test Fixture
  • 7.
    Tests of anApplication Layer. Domain Model Alistair Cockburn, Hexagonal Architecture Test Double almost allways when we interact with another service, or separated functionality We should be using Model as it is (without Test Double) Model can (should) be produced by a same Test Fixture From time to time we can use Dummy instead of an actual implementation.
  • 8.
    Tests in anInfrastructure Layer Domain Model Alistair Cockburn, Hexagonal Architecture Integration tests should prevail Unit tests should be used only for classes that contains logic required to implement the actual adapter, like Assembler, Query Builder etc. Good place for acceptance tests "Test Double" can be occasionally used for external interfaces
  • 9.