TubeSum ← Transcribe a video

The Secrets of Hexagonal Architecture - Nicolas Carlo - Bulgaria PHP Conference 2019

Transcribed Jun 14, 2026 Watch on YouTube ↗
Intermediate 8 min read For: Software developers with basic OOP knowledge who want to improve code maintainability and architecture.
1.8K
Views
45
Likes
12
Comments
0
Dislikes
3.2%
📈 Moderate

AI Summary

Nicolas Carlo explains the core principle of Hexagonal Architecture (Ports & Adapters): separating domain (business logic) from infrastructure (technical details). He demonstrates how this separation makes code more maintainable, testable, and adaptable to changing requirements, using a PHP example of a poetry reader that initially reads from the filesystem and can easily switch to HTTP.

[02:55]
The Problem: Changing Requirements

A project started with filesystem storage, then switched to FTP, then to HTTP. The speaker was able to migrate quickly because the domain logic was separated from infrastructure.

[05:23]
Core Principle: Separate Domain from Infrastructure

The universal truth for maintainable software: identify the domain part and the infrastructure part, then separate both. Domain is the business logic; infrastructure is the technical tools (databases, protocols, etc.).

[09:25]
Example: Poetry Reader (Traditional Approach)

A poetry reader class mixes file reading (infrastructure) with business logic (return default poem if none found). This makes testing hard and code brittle.

[16:09]
Hexagonal Architecture Explained

The architecture has a domain core and an infrastructure shell. The dependency rule: everything outside depends on the inside, but the inside never depends on the outside.

[18:34]
Using Interfaces (Ports & Adapters)

Define a port (interface) in the domain that expresses the business intention (e.g., PoetryLibrary). Implement adapters in infrastructure (e.g., FileSystemPoetryLibrary). This inverts dependencies.

[24:43]
Initialization Recipe

Instantiate right-side adapters (e.g., filesystem), then the domain with those adapters, then left-side adapters (e.g., CLI) with the domain. This wires everything together.

[28:29]
Testing the Domain

With the architecture, testing business logic is easy: mock the port interface. No need for actual files or databases. Tests are simple, fast, and reliable.

[33:06]
Benefits and Limitations

Benefits: plug-and-play adapters, defer technical decisions, easy to change protocols. Limitations: doesn't prescribe folder structure; need to decide where to put files. Clean Architecture adds more layers.

Hexagonal Architecture is a simple yet powerful pattern to separate domain from infrastructure, making software more maintainable and adaptable. Start by identifying the domain core and ensuring it has no dependencies on technical details.

Clickbait Check

95% Legit

"The title accurately promises the secrets of hexagonal architecture, and the talk delivers exactly that with clear examples and practical advice."

Mentioned in this Video

Tutorial Checklist

1 19:19 Identify the domain part (business logic) and infrastructure part (technical details).
2 21:19 Define a port (interface) in the domain that expresses the business intention (e.g., PoetryLibrary with getPoem method).
3 23:18 Implement an adapter in infrastructure that implements the port (e.g., FileSystemPoetryLibrary).
4 24:43 In the application entry point, instantiate the right-side adapter (e.g., filesystem adapter), then the domain class with that adapter, then the left-side adapter (e.g., CLI) with the domain.
5 28:29 Test the domain by mocking the port interface. No need for actual infrastructure.

Study Flashcards (7)

What is the core principle of Hexagonal Architecture?

easy Click to reveal answer

Separate the domain part (business logic) from the infrastructure part (technical details).

05:23

What is the dependency rule in Hexagonal Architecture?

medium Click to reveal answer

Everything outside depends on the inside, but the inside cannot depend on the outside.

16:49

What are ports and adapters in Hexagonal Architecture?

medium Click to reveal answer

Ports are interfaces defined in the domain that express business intentions. Adapters are implementations in the infrastructure that fulfill those interfaces.

18:34

What is the three-step initialization recipe for Hexagonal Architecture?

hard Click to reveal answer

1. Instantiate right-side adapters (infrastructure that provides capabilities). 2. Instantiate the domain with those adapters. 3. Instantiate left-side adapters (UI/CLI) with the domain.

24:43

How does Hexagonal Architecture make testing easier?

easy Click to reveal answer

You can mock the port interfaces, so you don't need actual infrastructure (files, databases) to test business logic.

28:29

What is the difference between Hexagonal Architecture and Clean Architecture?

hard Click to reveal answer

Clean Architecture adds more layers between domain and infrastructure, providing more granularity, but the dependency rule remains the same.

37:31

What is the 'screaming architecture' approach to folder structure?

medium Click to reveal answer

Name folders after business concepts (e.g., search, checkout) rather than technical layers (e.g., models, controllers).

36:58

💡 Key Takeaways

⚖️

Universal Truth: Separate Domain from Infrastructure

This is the core takeaway of the entire talk, presented as a universally applicable principle for maintainable software.

05:23
⚖️

The Dependency Rule

Explains the fundamental rule of Hexagonal Architecture: outside depends on inside, not vice versa.

16:49
🔧

Ports and Adapters via Interfaces

Demonstrates how to use interfaces to invert dependencies and achieve separation.

18:34
🔧

Easy Testing with Mocks

Shows how the architecture simplifies testing by allowing mocks of ports, eliminating infrastructure dependencies.

28:29
💡

Defer Technical Decisions

Highlights a key benefit: you can postpone choosing technologies until necessary, reducing upfront complexity.

35:10

✂️ Creator Tools: Viral Hooks

AI-generated clip ideas for Shorts based on the transcript

FTP to HTTP in one hour

60s

Real-world story of switching protocols in an hour without regression, showing the power of hexagonal architecture.

▶ Play Clip

The one rule of hexagonal architecture

60s

Clear, actionable advice: separate domain from infrastructure, with a memorable dependency rule.

▶ Play Clip

Why hexagonal is just marketing

60s

Reveals the origin story: Alistair Cockburn chose a hexagon because it's easy to draw, making the concept relatable and memorable.

▶ Play Clip

Testing business logic made easy

60s

Demonstrates how hexagonal architecture simplifies unit testing by mocking ports, a practical benefit developers crave.

▶ Play Clip

Defer technical decisions

60s

Challenges the notion of a 'good architect' by advocating for delaying technology choices until necessary.

▶ Play Clip

[02:55] put that in another but it was very

[02:59] convenient to start working because I

[03:01] can do that on my computer put some

[03:03] files on a folder run my application and

[03:05] thisif is moving so we starting working

[03:08] with the file system so we get unlocked

[03:10] and we starting adding features after

[03:13] one month they finally came with a

[03:17] protocol so they told us hey you will be

[03:21] using the FTP protocol so you can you

[03:24] know share files together the here are

[03:27] the credentials so you need to go back

[03:30] to the code one month's worth of code

[03:32] and everything you have done in that

[03:35] file with the file system you no need to

[03:37] use the FTP

[03:38] instead so I did that it was fine but

[03:43] then you can guess what happened they

[03:49] came back like two months in the project

[03:52] with the dead like coming there is no

[03:53] way we could move the deadline they came

[03:55] back and I say oops it won't be FTP like

[04:00] all the thing you have done that won't

[04:02] work you need to use HTTP not even HTTP

[04:06] HTTP so at that point what you should do

[04:11] you cannot move the deadline specs are

[04:14] changing that's life you should

[04:16] renegotiate the scope what's really

[04:19] important what needs to be done on the

[04:20] first of January so your application

[04:22] works this is what you need to negotiate

[04:25] and maybe there are some things we

[04:26] discussed we agreed on at the beginning

[04:28] but there are less important however in

[04:33] that case I went back to the code and

[04:36] like in an hour I actually was able to

[04:40] migrate everything from using FTP to use

[04:42] HTTP instead and I had no regression it

[04:46] was very easy for me to do that and not

[04:49] only that but since the very beginning I

[04:52] didn't even set up an FTP server on my

[04:55] machine and either I try to mock the

[04:58] other systems using HTTP to test my

[05:00] application well we're still using the

[05:03] file system on the development

[05:04] environments and then HTTP for the

[05:07] production and it's not because I'm a

[05:10] 10x developer or super coder or whatever

[05:13] it's because I know some tricks

[05:23] I want to tease you too much so I'm

[05:24] gonna give you right away the

[05:26] of this talk like that right at the

[05:27] beginning so if there is one thing you

[05:29] should retain from my talk today is this

[05:31] if you want to write a maintainable

[05:35] software there is one thing that is

[05:37] universally true that you should do

[05:39] which is first identify the domain part

[05:42] identify the infrastructure part and

[05:45] then you separate both of them this is

[05:48] critical so let me introduce these two

[05:52] terms my name is Nicolas I'm working in

[05:57] Montreal Canada for a nice company named

[06:00] buzz pod so at best but we do a web

[06:03] application for you to search compare

[06:05] and book intercity bus tickets meaning

[06:08] that if I want to go from Sofia to

[06:11] positive and I don't know Bulgaria

[06:13] because I'm a tourist I can still use my

[06:15] application and find a different kind of

[06:18] buses that they do find the best the

[06:20] cheapest one maybe or the fastest one

[06:22] and I can still pay in Canadian dollars

[06:24] or you can use that in travel to South

[06:27] America for example and pay in Euros or

[06:30] whatever currency you want every day at

[06:34] work we use some words so when we speak

[06:38] together developers project managers

[06:40] marketing people customer support people

[06:43] we share a vocabulary like we speak

[06:46] about seeds departures

[06:48] staffs round trips etc and we have the

[06:52] context around this word you probably

[06:54] don't understand leg the way we do in

[06:56] our context however taxes fees discount

[07:02] code that kind of thing you probably

[07:03] have that too if you're taking money

[07:07] from people if you are having a check

[07:09] out part in your application you

[07:11] probably have these words too regardless

[07:14] all of these words there are part of our

[07:17] business and we talk about these words

[07:19] regardless your developer or not this is

[07:22] your domain domain is or business and

[07:26] one could argue that this domain exists

[07:31] regardless there is a software or not

[07:33] you could imagine that we have a kiosk

[07:36] in every bus station in these 80

[07:38] countries with someone behind with

[07:41] you come see that person what are the

[07:43] best available oh you have all of these

[07:45] operators and here is the best one you

[07:48] pay money to us we get some commission

[07:50] and we make money now without software

[07:53] it will hardly be profitable that that

[07:56] won't be realistic software make the

[07:59] business profitable but it doesn't

[08:02] really matter what kind of technology we

[08:04] use behind for the cubes immersion here

[08:08] are some of the technologies that we use

[08:10] today so for example we store things

[08:13] into Redis and passe grid databases we

[08:16] could have used other kind of databases

[08:19] for example that doesn't really matter

[08:21] this is the infrastructure the

[08:24] infrastructure is what all of the tools

[08:27] that we have made together to make all

[08:31] of this work in real life but really the

[08:36] infrastructure part is a detail meaning

[08:39] that you can change it and it won't

[08:43] change the business this is something we

[08:47] miss Adam as developers we are here to

[08:50] solve the problem we're here to build

[08:52] the infrastructure to make the business

[08:54] work and because of that we focus too

[08:58] much on the solution and we tend to not

[09:01] speak that much about the problem that

[09:03] we're solving however at the heart of

[09:06] our software we are solving a business

[09:09] problem and it's important to keep that

[09:12] separation and to put the domain part at

[09:14] the heart of the software because this

[09:16] part won't change or when this part

[09:18] changes that means you're making your

[09:21] business grow let's see that on a

[09:25] concrete example so it's an example I

[09:29] really like which is let's imagine we're

[09:32] building a poetry as a service system

[09:34] and this is prince zero our project

[09:38] manager she is asking us to well as a

[09:41] user I should you know get a poem from a

[09:43] poetry library and if I don't get a poem

[09:46] you should return me the default one

[09:48] which is listed in the specifications so

[09:50] let's try to do that the

[09:54] usual way so if I was to do that and by

[10:04] the way I need to do a disclaimer these

[10:07] days since I'm at best but I mostly do

[10:09] JavaScript so my PHP is a bit rusty but

[10:12] the example is simple enough so you will

[10:14] follow so at some point I will create a

[10:17] class which I will call a poetry reader

[10:19] because yes it will read some poetry and

[10:21] this class it will have a public method

[10:24] which I will call give me some poetry

[10:26] because like I'm using the words that

[10:30] were in the specification sounds fine

[10:32] this thing should give me some poetry

[10:34] now where do I find the point so I ask

[10:39] the question this is print 0 there is

[10:41] some kind of author system that will be

[10:44] writing the poem somewhere on the file

[10:46] system in a text file so I should really

[10:49] just go and read the content of that

[10:51] text file and because this is vs code so

[10:55] you can see here it's a bit small but I

[10:58] do actually have a text file so this

[11:00] thing will work this thing will be

[11:03] located in my assets folder and if I

[11:07] don't have a poem well I should go use

[11:10] the default poem that we agreed on which

[11:13] is poem from Alastair Coburn who coined

[11:17] the exact normal architecture terms

[11:19] originally and then I returned that

[11:22] point okay I do I make this work well at

[11:28] some point I need to instantiate the

[11:29] poetry read your class and then I will

[11:34] just use my CLI here to see the result

[11:36] of that so I will echo quash reader give

[11:40] me some poetry okay let let's try that

[11:44] so I told you this is this is just a

[11:47] file nice so I get something it's a

[11:54] French poem but wait a minute because in

[11:57] French we have some accented characters

[12:00] and seems that we have an encoding

[12:02] problem my favorite kind of problem

[12:06] so yes there is this problem and we

[12:10] asked the project manager what's

[12:11] happening and turns out the the file

[12:14] we're receiving is not encoding using

[12:17] utf-8 so we need to you know convert the

[12:20] encoding and hopefully in PHP well we

[12:23] have a function for that so MB convert

[12:27] encoding give it the poem I want that in

[12:30] utf-8 and turns out the encoding use is

[12:34] a Western encoding whatever is a thing

[12:39] so let's try that again and here it is

[12:43] it works so classic short basic example

[12:49] of what it will look like to to develop

[12:51] that kind of feature traditionally we

[12:54] just go and solve the problem and make

[12:57] that work and that's it but there are a

[12:59] couple of problems with this and the

[13:02] main problem I would like to focus on it

[13:04] the fact that we have mixed the domain

[13:06] part with infrastructure part where is

[13:09] the domain well the pwetty reader give

[13:12] me some poetry this is just domain part

[13:16] then the file get contents and

[13:19] converting the encoding and all of that

[13:20] this is infrastructure details I can

[13:23] probably not ask my project manager to

[13:26] read that code and understand what it

[13:28] means however the rest if there is no

[13:32] poem the poem then should be the default

[13:34] one and return the poem this is again my

[13:38] business logic that my project manager

[13:41] can understand and read the code the

[13:46] problem of mixing both together is that

[13:49] first of all it makes the hard for you

[13:52] to see what is the business logic in the

[13:54] middle of all the infrastructure details

[13:57] you can imagine some queries to

[14:00] databases and queries to HTTP services

[14:03] right in the middle of there is some

[14:05] business logic here and because of that

[14:09] it's hard to test the business logic

[14:11] like I don't have the time to test this

[14:15] but if I were to test that I will either

[14:17] need to have an actual

[14:19] set up that like provide me a text file

[14:23] with the poem and one without the poem

[14:25] so I can test the behavior of my

[14:27] application in both cases and then I

[14:29] will need to figure out how to listen to

[14:31] the output of the CLI or I would mock

[14:35] the low-level details like file get

[14:38] contents so I can control what happens

[14:40] here but that will be terrible and I

[14:44] will need to rewrite that test every

[14:46] time I need to change how I retrieve the

[14:48] poem so usually it's hard to test the

[14:51] business because of that so it's hard to

[14:53] test the code so people don't test the

[14:55] code or not all of the business

[14:58] requirements and when you don't test the

[15:00] business requirements when you do change

[15:02] the code for any reason then it's very

[15:06] likely your code will break which is a

[15:08] problem also something I want to mention

[15:14] some people think that this will be a

[15:18] very valid refactoring you know to make

[15:21] that code bit easier to read I will just

[15:24] extract the infrastructure part in a

[15:27] function like read encoding file take

[15:30] file name and return me the poem the

[15:42] path where something like that okay so

[15:47] yes

[15:47] that's a valid refactoring extracting a

[15:50] function but that doesn't change

[15:51] anything to the fact that your domain

[15:54] still depend on the on the file system

[15:56] here so better readability but in terms

[16:00] of testing you still have the same

[16:02] problem so this is not what I'm talking

[16:04] about let's see how to solve that and

[16:09] let's discover what is exactly null

[16:11] architecture to me exactly an

[16:14] architecture it's the simplest way you

[16:17] could have to do exactly that to

[16:19] separate the domain part from the

[16:21] infrastructure it's a simplest way how

[16:24] simple that simple like you can how they

[16:28] do is more simple than two potatoes on

[16:31] the screen

[16:32] this is a simplest architecture I know

[16:35] and I just didn't draw two potatoes on

[16:40] the screen randomly I put the domain

[16:41] part at the heart of my acute

[16:43] architecture and that's because there is

[16:46] one rule which is the dependency rule

[16:49] and that rule says that the everything

[16:53] that is outside depends on the inside

[16:55] but the inside cannot depend on the

[16:58] outside and this is critical that means

[17:01] your domain should not know about the

[17:04] infrastructure part so where is the

[17:09] exact on here it is and this is

[17:12] something you should know about the

[17:13] exact on there is nothing about the

[17:15] exact on like exact on all is a

[17:19] marketing word because as I said Coburn

[17:23] so we coined the term exactly

[17:25] architecture originally named it ports

[17:28] and adapters architecture and that will

[17:30] make sense but is also a consultant I

[17:33] was a consultant when you are a

[17:36] consultant you need your IDs to stick in

[17:39] people mind so geometrical shape it's

[17:42] easier to remember like it's really

[17:44] marketing thing and that's a true story

[17:48] because he told us that it's an exact on

[17:51] because you know it's very easy to draw

[17:53] it's very symmetrical compared to like a

[17:55] pentagon it has not too few sides not

[17:58] too many so it's very convenient and

[18:00] that's it so this is something you

[18:03] should know about the executive

[18:03] architecture exactly know is marketing

[18:06] but the core which is inside we will see

[18:10] in a moment so let's focus on the exec

[18:13] on how do you make the domain not depend

[18:17] on the infra but at some point I need to

[18:20] go and read that file on the file system

[18:23] if you're doing object-oriented

[18:25] programming which I guess you are doing

[18:27] if you are using PHP you should know

[18:30] that we have solved that problem long

[18:32] time ago using something we call

[18:34] interfaces so this is an abstraction

[18:38] this is your intention and this is your

[18:41] business intention because yes I need to

[18:45] get my poem from

[18:46] poetry library whatever this poetry

[18:48] library is so my code my business code

[18:52] will depend on that intention and then

[18:56] somewhere in the infrastructure layer I

[19:00] will have an implementation and adapter

[19:03] that is saying okay I will get you to

[19:06] your poem an approach library and that

[19:09] will be using the file system and when I

[19:12] do that I switch the dependency I invert

[19:17] the dependency between the

[19:19] infrastructure and the domain you take

[19:23] the interface you call that a port and

[19:25] there you have the ports and adapters

[19:27] architecture and there this is

[19:29] everything that is about this

[19:31] architecture you put ports inside your

[19:34] domain and then you build different

[19:36] adapters on the infrastructure side

[19:39] super important inside your domain it's

[19:43] not just any kind of interface

[19:45] abstraction like it won't be an HTTP

[19:47] interface it's a business oriented

[19:51] interface again your intention pay

[19:55] attention to the business language try

[19:57] to foster that business language inside

[20:01] your domain and that will be better for

[20:03] everyone we have two sites for the

[20:09] adapter that's just a convenient way to

[20:11] distinct the two kind of adapters that

[20:14] we can have the first side is on the

[20:16] left and it's everything that is

[20:19] exposing your application to the outside

[20:21] world so that could be for example a UI

[20:24] or a CLI which was my case here or it

[20:28] could be a REST API and that also means

[20:32] that I could plug another way to consume

[20:36] my application without changing anything

[20:38] about the application and by the way

[20:42] tests are just another consumer of your

[20:45] application in a sense so if you're

[20:47] building for production for a UI for

[20:51] example you at least have two kind of

[20:53] consumer one being the test on the right

[20:58] side you have everything that is needed

[21:00] by the domain to do it stuff so typical

[21:04] things are occurring things from a

[21:06] database or from external web services

[21:10] let's go back on our example and and try

[21:13] to do that but applying exact normal

[21:15] architecture for real so I will start

[21:19] with the domain because I can start

[21:22] coding the domain with the business

[21:23] requirements that I don't care how the

[21:25] thing is implementing exactly this is

[21:28] like pure logic so we'll start with the

[21:30] domain part in the domain I will well

[21:34] create my poetry read your class again I

[21:37] will keep my give me some poetry

[21:40] function because this were really nice

[21:42] and everyone understand that and then

[21:45] when I reach it the poem this is how the

[21:50] magic happen I will read the

[21:52] specification again and this is saying

[21:54] you should get a poem from a poetry

[21:57] library and if it doesn't say that go

[22:00] and talk with people try to understand

[22:01] what is the logic behind what are the

[22:03] words so I will just try to reflect that

[22:06] in the code I got some kind of virtual

[22:09] library here and this has a get a poem

[22:11] method I think in a decision here then

[22:15] the rest of the logic is the same if

[22:17] there is no poem I should default on

[22:19] Alistair Coburn poems and then I really

[22:24] return the poem okay I need to get that

[22:28] poetry library and that I will inject in

[22:32] the constructor I don't know exactly

[22:34] what is the poetry library

[22:37] implementation but someone will know and

[22:40] give it to me and implicitly we could

[22:47] make it explicit but there is this

[22:49] interface of the poetry library and it's

[22:55] kind of a contract like I don't care how

[22:57] is it implemented but what I do know is

[23:00] this thing needs to give me a get a poem

[23:04] method so you can build any kind of

[23:07] poetry library as long as it provides

[23:10] this contract for

[23:12] this contract okay so let's move on the

[23:18] infrastructure part everything is done

[23:20] on the business side and now we need to

[23:23] make things happen with the file system

[23:25] so on the infrastructure side I will

[23:31] build a file system adapter here my file

[23:34] system adapter will need to know about

[23:36] the domain because I will be

[23:38] implementing the interface and the

[23:40] interface is defined in the domain so

[23:43] that's how the infra depends on the

[23:45] domain part so I will do a file system

[23:47] virtual library that implements the

[23:50] poetry library interface and because it

[23:54] implements the poetry library interface

[23:55] I need to provide a get a poem public

[23:59] function so let's do that and what is

[24:03] the implementation of this it's the one

[24:06] I had before I don't like the technical

[24:09] solution still needs to happen but I

[24:12] will put that solution here and all of

[24:14] the concerns around encoding for example

[24:20] will be here and the business doesn't

[24:23] change because of that so utf-8 and is

[24:26] OAD i-59 okay and I returned that point

[24:33] okay so I have my domain part I have

[24:36] mine adapter now I need to make that

[24:39] thing connects together or it won't work

[24:43] at some point in your application you

[24:47] have the entry point of your application

[24:49] and when you do exactly architecture we

[24:54] use the three steps initialization it's

[24:56] always the same recipe so I'm giving it

[24:59] to you right now the first thing you do

[25:03] is you instantiate the right-side

[25:05] adapters the right-side adapters are the

[25:08] one who provide the domain with like

[25:10] capabilities so in that case the file

[25:13] system virtual library this is a

[25:15] lifestyle editor so I will instantiate

[25:18] that and if it was an HTTP boy to

[25:22] library tomorrow and I need to

[25:23] authenticate this is

[25:25] I will provide the configuration for

[25:26] authentication I won't go in and pass

[25:29] this information to my domain part it

[25:32] won't care then as long as I got my

[25:36] adapter I can instantiate my poetry

[25:38] reader and I will pass the filesystem

[25:40] poetry library in that case but you can

[25:43] imagine I pass any kind of other adapter

[25:46] at runtime and in the end I need to

[25:52] expose that so in this example I'm using

[25:56] a CLI so I will imagine that I define a

[25:58] CLI adapter enjoy infrastructure and I

[26:02] will pass to that adapter the domain so

[26:05] this adapter doesn't do the business

[26:08] logic it's the role of the exec on the

[26:10] domain part but it exposed that like to

[26:14] the tli for example and then when I'm

[26:17] here really I have everything so I will

[26:20] put the app logic and the app logic it

[26:23] will use the left-side adapters so in

[26:27] that case I can like echo some here is

[26:32] some poetry give it some space and then

[26:36] I will use my right side adapters to you

[26:38] know do stuff so ask for poetry for

[26:42] example or it could be anything this is

[26:44] like I'm using the right side adapters

[26:46] in my entry point to kickstart my

[26:49] application and export that to the

[26:51] outside world ok I need to go back

[26:54] implement that CLI adapter so remember

[27:01] the left side adapters are how we what

[27:05] we use to expose the application so I

[27:11] completely arbitrarily decided to name

[27:14] that CLI and this should have this will

[27:17] take the domain in the constructor it

[27:21] will be injected so it won't know how to

[27:23] actually do the logic so we'll just tour

[27:27] that and it will have a method that I

[27:31] call give ask some poetry and what does

[27:35] this method do well it will expose

[27:38] to the CLI the results of my eggs egg on

[27:41] so in that case I will just echo the

[27:45] result of it but really this is a point

[27:48] where I could for example take input

[27:50] from my user and provide that to the

[27:53] eggs a column to executor logic and

[27:54] return that so I have everything is in

[27:59] place that should work I will call that

[28:04] so 0 2 0 3 yes it works so see I've

[28:13] solved the same problem but I've used a

[28:16] different kind of architecture it's a

[28:18] bit more code but it's not more complex

[28:22] not that many much complex and I do have

[28:26] time to show you how I will test the

[28:29] domain part because now it's super easy

[28:30] to test the domain part and all of the

[28:32] business requirements I can test super

[28:34] easily so for that I will use PHP unit

[28:40] and I will test my part you read your

[28:43] class so I can test the happy path the

[28:48] default behavior which is it should give

[28:51] me some poetry from the library usually

[28:56] I recommend you write tests first

[28:58] in that case for the flow of the talk I

[29:01] write them after but it's good to start

[29:04] with them first because you start from

[29:06] what you wish you have also I structure

[29:10] my tests with a given one then structure

[29:14] arrange a third act also it's another

[29:17] name for that and I start with the then

[29:19] part because the then part it's the

[29:21] final outputs so here I'm asking to

[29:25] myself why do I wish this thing do well

[29:28] I wish this thing returned me a result

[29:32] that will equal to the poem I will

[29:35] define okay very generic but now I know

[29:39] that I need first of all the result of

[29:42] my call which is the when part when part

[29:47] is what are you testing exactly in that

[29:50] case I get the result

[29:52] a call to the give me some poetry so far

[29:56] I don't really have to think I just have

[29:58] to apply like the recipe okay now I have

[30:03] to think a bit where do I find the

[30:06] portraiture well I guess I need to

[30:08] instantiate it so I will imagine that

[30:10] everything is ready for it so I wouldn't

[30:12] sting my poetry reader and I know

[30:15] this thing takes a portrait library okay

[30:18] so now I need to provide it a poetry

[30:20] library and I told you that the portrait

[30:24] library can really is any thing that

[30:28] implements the interface so in that case

[30:31] I will provide a mock and that mark

[30:34] won't change it won't change for

[30:40] technical reasons if that mock changes

[30:43] that means my business is evolving my

[30:45] intention is changing so that mock is

[30:48] fine I am controlling the context so I

[30:53] can test the logic of my poetry reader

[30:56] and in that case I will control the get

[30:59] appoint method and in that case I will

[31:02] return the poem that I no need to define

[31:05] so we'll give it another poem I stored

[31:09] from Misawa cheeky alright so here is my

[31:15] test simple to read I don't care about

[31:18] the file system or anything let's try

[31:21] that so I've got some PHP in it here

[31:26] [Music]

[31:30] yeah let's quickly do the next test so

[31:36] how would that test that it returned me

[31:39] the default poem if there is no poem

[31:43] well the beginning is the same I start

[31:47] with the then part it should equals that

[31:51] poem of from Alastair Coburn from my

[31:55] results what is the result

[31:57] it's the same call it's usually the case

[32:00] like your when part is always the same

[32:03] between your tests

[32:05] so I need the poetry reader again so I

[32:11] really it will be the same thing that

[32:14] takes a poetry library and the poetry

[32:17] library again it's the same thing it's

[32:19] still a mock of my interface and the one

[32:27] thing that changes here is that this

[32:30] mock it will return nothing so this is

[32:36] how easy it is to test the different use

[32:39] cases and I can run that again and it

[32:44] works no when the tests work for the

[32:48] first time always be suspicious so I'm

[32:51] just gonna make it say something oops

[32:58] okay

[33:00] it feels so it works and that's it

[33:06] that's how you do exactly no

[33:10] architecture that's everything you need

[33:13] to know and when you know that you know

[33:16] all of the basics but I realize that

[33:19] most of the time because it's so complex

[33:21] Lee told people don't really understand

[33:24] that basics and don't apply that basics

[33:26] so let me finish on the prose and also

[33:29] the limitation of it the first thing I

[33:32] want to say there is nothing new in

[33:34] everything that I said if you're doing

[33:38] object-oriented programming programming

[33:40] to an interface and all of the solid

[33:42] principle most of them are about

[33:43] interfaces really they're compatible

[33:47] with that there are about that if you

[33:49] follow that if you're doing functional

[33:52] programming instead it's not that

[33:54] different in functional programming you

[33:57] easily the side effects of your system

[33:59] with the i/o monad and you put that at

[34:02] the edge of your system because at some

[34:04] point you need to talk to the file

[34:06] system or to the database so it works

[34:08] this is why you are getting paid for but

[34:12] you don't want that to be spread

[34:14] everywhere in your application so you do

[34:16] like a functional pure

[34:17] core and then an imperative shell also

[34:20] called the onion architecture and this

[34:22] is the same domain infrastructure maybe

[34:26] the difference will be on what language

[34:28] do you use inside your functional core

[34:31] is this just mathematical functional

[34:34] monads and things like that or do you

[34:36] want to express the business language

[34:38] instead it's up to you the good thing

[34:42] about that as you might understand you

[34:44] can plug any kind of adapter to the

[34:46] domain it's a plug-and-play architecture

[34:48] if tomorrow I need to switch from the

[34:51] FTP to the HTTP it's not more complex

[34:54] because we're two month in my adapter is

[34:57] like 50 lines long what I need to do is

[35:00] just to provide another implementation

[35:02] of the few methods using another

[35:05] protocol and this is a short thing to do

[35:10] that means you can defer technical

[35:14] decision and this is what in my opinion

[35:16] a great architect can do it's not like

[35:19] when you're a good architect you have a

[35:23] lot of experience with different kind of

[35:25] databases so you're able to answer the

[35:27] question what kind of database do we

[35:28] need to use you are the senior developer

[35:31] so you might you should know that my

[35:33] preferred answer is we don't care for

[35:37] the moment like I will give you the best

[35:40] educated guess with the information we

[35:42] have now but really until we are in

[35:44] production do we really know exactly so

[35:46] do we need to go for the fancy complex

[35:49] stuff right now or can we ship fast with

[35:52] a simple solution that works today that

[35:55] is reasonable and if we need to change

[35:58] tomorrow we will be able to do that

[35:59] without it being too complex because if

[36:03] I can make the change in one month and

[36:05] it's still as easy to do the change it's

[36:08] fine it's not fine when you know that

[36:12] you're committing to a technology and if

[36:15] you're committing to it in six months it

[36:16] would be hard for you to change the

[36:18] technology it's only the first step

[36:22] though and this is a limitation I was

[36:24] able to do that in 35 minutes

[36:26] that means you will have a lot of

[36:28] question when you apply that in actual

[36:30] production code the usual question is

[36:33] where do I put the files well it doesn't

[36:36] tell you anything about that and I will

[36:38] tell you it's up to you it depends on

[36:41] the majority of your team on how you're

[36:43] comfortable can you make the framework

[36:46] just live in the infrastructure part it

[36:49] will be ideal some people start with

[36:52] like a folder domain a folder

[36:54] infrastructure and split like that I

[36:56] tend to prefer using something we call

[36:58] the screaming architecture which is I

[37:02] put the business in my folder names so

[37:07] when I'm looking at the architecture of

[37:08] my application oh there is search and

[37:11] check out one way roundtrip you're in

[37:13] the transportation business it's not

[37:15] just any model-view-controller kind of

[37:18] folder technical one and I don't know

[37:21] what you're doing exactly but really

[37:23] it's up to you I will recommend you to

[37:28] go start with that and then go further

[37:31] with the clean architecture it just

[37:34] gives you more layers so it answers the

[37:36] detailed question like okay this thing

[37:39] is more to the outside world and this

[37:41] thing is more like it's it's closer to

[37:44] the business but not exactly where do I

[37:46] put that this thing gather the existing

[37:50] knowledge about the different kind of

[37:52] architecture and gives you more layer

[37:54] but the rule is still the same

[37:55] dependency rule from the outside to the

[37:58] inside so start with extracting the

[38:02] domain part and make that not depend on

[38:04] the infrastructure this is the first

[38:05] step you need to do and finally if you

[38:09] want to build a strong domain like this

[38:12] domain part you will have a lot of

[38:15] classes inside and more and more

[38:16] business logic and to make that grow if

[38:19] you're not building a prototype if

[38:21] you're not in a hackathon if you're

[38:23] building something you're making money

[38:25] with and you aim to maintain for more

[38:27] than one year I strongly recommend you

[38:30] to bring your team to get into domain

[38:33] driven design not really much for the

[38:35] technical patterns that are interesting

[38:38] but they're not the most interesting

[38:39] thing

[38:40] but about the importance of the language

[38:42] and the concept that you can have

[38:44] different models you you don't have to

[38:47] have one big departure model to

[38:50] represent everything in your application

[38:52] but you have contexts that's it

[38:57] please remember Monday at work start

[39:00] thinking about domain infrastructure and

[39:03] how you could separate them both thank

[39:07] you very much

[39:08] [Applause]

[39:14] yeah we have I saved two three minutes

[39:17] for the questions if you have some

[39:19] please go ahead

[39:34] hi thank you for a speech it was really

[39:38] great but I have question it really

[39:40] seems to be a domain-driven design but

[39:43] you forgot to talk about application

[39:45] layer and you kind of mix it together

[39:48] with infrastructure would you like to

[39:51] know why and I have second question more

[39:54] practical from my practice so should all

[40:01] exceptions be converted to domain

[40:11] you

[40:28] clean architecture or other kind of

[40:31] architecture that introduces that player

[40:32] I told you you need more layers in the

[40:35] infrastructure and the application layer

[40:36] in is in the middle it's more the

[40:39] infrastructure side really going to

[40:41] clean architecture you will you have

[40:44] more information about that and

[40:46] regarding the so I have an exception

[40:49] should should I convert that into the

[40:51] domain exceptions all the exception

[40:53] including the infrastructure one no it

[40:56] depends if it's a purely in frustration

[41:01] it's a technical exceptions so it's fine

[41:03] to have a mix of both in your

[41:05] application how you do that might be

[41:07] interesting to discuss but we don't have

[41:09] time I will stay outside if you want to

[41:14] dig into more details of that kind of

[41:16] question but yes you can have both kind

[41:19] of exceptions in your application

[41:20] overall final question I know there is

[41:29] lunch all right thank you very much

[41:44] you

⚡ Saved you time reading this? Transcribe any YouTube video for free — no signup needed.