This presentation is brought to you by RingCentral developers. Revolutionize the way your business communicates with RingCentral's API for voice, SMS team messaging meetings and facts. Don't just be a developer. Be a game changer with RingCentral developers. So a HIO [inaudible] my name is Milko Kosturkov for don't believe my slides. I'm a PHP developer for over 13 years as Mike said not 12. I've been doing a full stack pretty much most of my careers. So I'm also interested in the front end, not only on the backend of stuff, making things happening in the, in the, in the browser world. Educational-Wise I have bachelor's in electronics, masters in ID. Right now I'm working as a contractor and I found that my own company tie software almost a year ago. And a, as Mike said, most important right now for me is a Bulgaria PHP conference 2019, which I'm actively organizing just a quick correction on my side.

It's not going to take place in two weeks. He's going to take place in two months. So there's plenty of time to get your self tickets and, book your, your, your flights and hotels and stuff. It's going to be amazing. The lineup we have is, it's, it's, it's great. We had the great CFB and it's just great. So anyway, I bought the fields I've worked in as Mike said, lots of various stuff. I started with SMS voice services continued with multiplayer, massive multiplayer online games. I've been involved in a healthcare software for doctors without borders. This was very interesting theory. Predictions were a massive thing. That's let's see if, if you, if you think that you know what a deadline is in Kevin worked for TV production, that you don't know what the deadline is. Deadline is APN when the live show starts.

So lots of things not, not that important right now. More importantly, I will start with why this talk, why, why do, why, why am I doing this talking? Why do I want to talk about MVC and what my problem is with MVCs as the title maybe says it clearly enough. I have a problem with NBC. Every sport would be we co MVC. So first of all we're going to take a look at the past. Why? Well, because we need to know our past. And I have not does it every five or 10 years or so. Developers are reinventing the wheel. We concepts that were invented in the 60s, the 70s, the 80s. And we're always so amazed. We found out the solution to the greatest problem that we've had that existed for nearly 40 years and give it another name and we start writing a blog posts about it in high development.

And all of this, all of this usual has been invented long, long, long ago. But, but nobody took the time to read it. Nobody knew that it has been invented for whatever reason, nobody knows. Our past second, and this is a, this is particularly for, for them to see, there is a lot of confusion, at least I experienced a lot of confusion when I, when I first dealt with MVC when I was a younger developer because what I was reading on the internet and in blog posts and Wikipedia and technical documentation about MVC was in total contradiction with what I was seeing as code, what I was being explained explained by older developers, more experienced developers. It, it, and I was totally confused. So what I, what I'm going to do, what I'm doing with this talk is basically go through the past, reach for the past and tell you what happened, how it happened so you're not as confused as I as I was because it took me probably seven years or so to, to, to understand what is going on with this MVC pattern.

And next I'm just going to introduce quickly you and better concepts in the state of teachers instead of NVC. Because as I said, I, I don't, I don't like the way we do stuff with the current understanding of, of, of embassy. So let's start with a flashback on a why and how and when NBC was implanted. So that was the year 1979 and it was invented by this Norwegian guy by the name of thrill, the last calc and if there are any original solution to this and I didn't pronounce it right I apologize. It's very, very hard for me. He is now a professor. He was born in 1930s. You alive. I wish him the best. He invented. And we see while he was working with Xerox and surprise, surprise, you did not invent and we see and did not think about the web at the time because there was no such thing as the web. But instead it was trying to figure out how to make graphical user interfaces for applications.

And at that time they were working with a small talk, a and a small talk is the, by the way, and object oriented language. And there were, we're trying to figure out how to, to do software for Dynabook. Now Dynabook was the, the, the idea of Dynabook was to be a personal computer for children of all ages. And it was a portable computer. It kind of resembled what we call today a laptop or a tablet. So it was something like a mixing between, the most important part about Dynabook is that it had a graphical user interface. And also very important part was that the developers that were working behind the, in the engineers that were working behind Dynabook, they wanted the user, the owner of the Dynabook to understand and to be able to write the programs for Dynabook himself. Yes. Well they were trying to achieve and we see as a general solution to the problem of users controlling a large and complex data set. So that was a quote. So basically they needed to find a way to present user we data to make it easy for users to control this data, modify it, red programs doing that.

So next thing I know that the flights with a lot of facts and reading off slides is generally not a very good idea, but I'm going to do this anyway because we need to coin some definitions about MVC. So please bear with me. So these are definitions that we're calling by a [inaudible] scout himself. That's why I really, really want to be very punctual about them. So the first definition that we're going to go through as the definition of a thing, so according to Craig veteran's cock a think is something that is of interest to the user. It could be concrete, like a house or an integrated circuit. It could be abstract. Why can you idea or opinions about the paper? It could be a hole, like a computer or a part, like a circuit element. So basically he's described the anything that can exist in real life.

This, this is, this is a thing and what we're going and, and what MVC is trying to achieve is represent things gap. The bridge between users. Usually your vision of a think idea of a thing. And a computer model about it. So the next thing, next definition that we're going to read is model. Again, according to Craig, vet ordinance, Coke models represent knowledge. Although it could be a single object rather uninteresting or it could be some structure of objects. There should be one to one correspondence between the model and its parts on the, on my hand and the representative, the representative, the world is proceeded by the owner of the model. On the other hand, okay. So basically this is the definition of a model in, in, in any case, like when, when we wallow stuff, when we model things, the model is a representation of a thing that existing reality, the motto is usually something that represents this thing from a [inaudible] perspective and is not entirely detailed.

It is detailed to a needed part to which we can, we can, we can, we can get the idea without the, the, the, all the complexities. So a model in an MVC is basically a computer model of, Oh, you think of something that exists, it represents his behavior, represents a state next definition of view. So a view is a visual representation of its model. It would ordinarily highlight certain attributes of the model and Cimpress others of you is attached to its model or model part and gets the data necessary for the presentation from the bottle by asking questions. The view will therefore have to know the semantics of the attributes of the model, which represents, okay, so again, this is view from the perspective of MDC. What it basically means is that a viewer will draw something on the screen and this something will represent a certain aspects of the model that the view draws.

I will later show you a screenshot of a computer aided design system, which very well illustrates different views for the same model and last control controllers. So again, by trig is cock. A controller is the link between the user and the system. It provides the user input per arranging for relevant views to represent themselves inappropriate places on the screen. He provides meetings for users output by representing the user with menus or means of giving commands. And data is basically nice that it controller listens for clicks and keystrokes will never input the computer can, can, can handle and then it communicates those to, to, to the model. Now this is very important. A controller should never supplement the views. That means that a controller would never try to manipulate a view if just give it a place on the screen for the, for to render. And then conversely, a view should never know about user inputs such as mouse operations in keystrokes. Okay. That means that the view will not ever be aware there is a mouse or keyboard appointing device. Whatever. I, I cannot really think of more input devices right now.

So thank you for bearing with me with treating those lights. There was a lot of fixed. Now let's see how those tree work together in the classic MVC way. Now this diagram is probably the one diagram that I've seen most often on the web and it basically describes this, the user uses the controller and then the controller. When you believe the model, then the model of days, the view, and then user sees the view. This is somewhat correct, but I'm not very happy with the direction of the arrows and doesn't really give us details about how interactions between those tree are happening. So a will broader prefer to use this diagram to explain it. So basically what happens is that the controller defines application behavior. It maps user actions to model updates. It's the legs views to response one for each functionality. So basically the controller orchestrates the views, tells the views again, where to draw over themselves and listens for user input.

And then when the controller catches some sort of a user in book, like a mouse click or a keystroke then it manipulates the model. The manipulation of the model happens through the controller evoking some sort where the method from the model and this changes the state of the model. Maybe now the motto encapsulates applicational static state response to state queries. So basically it represents the application and what is going on. It's state its behavior. Once the model gets updated by the model [inaudible] it notifies the view that there has been a state change. This cap post for the means of events. The model does not know what the view is. The model does not go any methods on the view. It just fires the methods or use the observable refactoring or whatever. That's not fair as a method, I'm sorry, far as an event and the view then responds to this event.

The response of the view is to probably the model about what has happened. Again, I say, okay, did a label change of the your dimensions change? What, what happened? The view examines the model at examined sets for stuff that are of interest to the view and then renders updates the screen. Then rerender is whatever interesting happened and displays it to the user. So this is much embassy as it was designed. Originally it took some iterations. It took some changes and I don't think that they ever really got it right. It it had a lot of problems that they continued to search. How, how to solve. So it wasn't exactly totally perfect, but this was the original idea afterwards of all of a lot of concepts worthy developed based on this, a lot of other improved concepts, but this was the original, and we're not going to go into much more detail now.

I said this light you can see a screenshot from a cut the program. So cut programs, cat stands for computer aided design. So computer aided design programs are used to model a physical world. So basically make drawings of buildings or machines or different parts for machines, stuff like this. And the reason I'm showing this screenshot is because actually before he went to Xerox and the developed NBC trigger was developing cat systems. So they are a very good example of a implementation of MVC. So the model in this particular case would be a building and we would be looking at tree views of the same building of it's of the same, a part of a building. It's the stairs that we're building. So on the right, we have a threeD view of the, of the stairs, so we can see their color, some of their material.

We can see how they will generally look. In the center. We see a drawing, a schematic from the top perspective and it shows different details about how this building should be made. It shows what kind of materials are used. This little strokes are actually different materials. Each will be chose where the where the doors are and you chose where the doors are being opened. So stuff like this, it's the same stairs, different accent in different representations, different views on the same model. On the left we have a lift of lists, I'm sorry, a list of properties of the stairs. And they have a, for example, length of the stairs. They have some commands that the architects could do. They have floor plans ceiling plans, we'll list of things about this building. So again, a different representation, different view of the same model and the controllers for each for the controllers for this detect weather. For example, the user will drag on a view and then the controller will tell them auto, okay, you're being represented to this. They mentioned on the deal with Redrow itself. So this is pretty much what Angus fee was designed for. Graphical user interfaces.

Now, how, how does this map to, let's call it web MVC and what we do, let's, let's make a, let's make a quick comparison. So first application life cycle of the applications that [inaudible] used them. So MVC was designed for applications that have long run duration and by a long run duration, I mean, you start the application, use the application for a certain amount of time. That can be one minute, five minutes, an hour, two days, three days, whatever, as long as you need it. And you turn on the application. When you decide and throughout the life cycle of the application, you would have continuous simple and that would be multiple clicks, multiple keyboards, folks, multiple dragon drops, multiple scrolls.

And then for each of those you would have output. So the output would be a view update. So this would go on and on and on. Do you close the application? So w well, NVC rather web applications. What we have in the specialty PHP applications, what we have is a short term duration. So you basically make a request to the server, a script gets executed, it does something, and then it ends, you have one time input. One time it would be with your requests, you sent your post data, your your query, your request body, your cookies, your headers. And that's it. There is, there is no more input. It's one time the server receives the implant walls and that's it.

And then we have one time output because basically what the server those or your script does is it assembles some sort of an output. It's that some headers and then it sends this to the user and that's it. So [inaudible] it resembles this, this guy's workflow. It resembles more a command line, a application rather than, than, than gooey, gooey, graphical user interface interface application. So let's look at models. So with classical MVC, the motto holds the state of the application. It describes the behavior of the application and these basically a reflection of reality. Yeah. Now what we have with web MVC what we do with our amplifications, what we call a model, it's basically a database access layer or a database table with my bank and a pretty much nothing more. It's, it's, it's, it's that, it's what you have in your database.

And believe me, I have actually heard this quite a lot. Like when I was younger I would ask what is a model? And my colleagues will say, well for every table in the database you have a model and I couldn't understand how, how come, how, how does a table represent behavior? And they asked, the reason doesn't, it's the database is just a storage for your data anyway. Let's go on to use. So we classic can we see views, views? No. The models views have to know what the models represent so they can draw them and ask them particular questions and put accents on particular things. And views represent the state of their respective models with what we see. Surprisingly, it's pretty much the same. So with a view, we represent the state of their respective model and the views, no, the model, now I have put a little asterisk here because usually what we see is that the view doesn't actually communicate with the model itself, but it's actually assigned variables or Aries or whatever kinds of data. And then the view interprets that data. But we can still somewhat say that this data is a representative is, is, is a model sense. It usually comes from the models.

Okay. Next. And my favorite actually controllers. So with classic canvas, see the controller's job, just the response to user input by calling methods or models. So this is clicks, keystrokes, whatever. And it will, it will detect a mouse move. It will take the click if we take a keystroke and it will go the corresponding method on the model. It would also be in charge of selecting which views to display and where do display them on the screen. Now, well, does our web, MVC controller does. Our web. MVC controller is pretty much the God emperor of your application. So what it does is it response to user input because you know, this is, this is where you handle the HDP requests that you get. They contain a good portion of the application's behavior. And by that I mean that they take very important decision on how the data is going to be manipulated when it's going to be stored, what kind of actions are going to be taken based on the data that is input that is in the database.

They, they, they, they basically contain the so-called business logic. They conduct the behavior of your application. They handle input validation. They hold the dependencies for whatever services you would need. They select only one view. Usually, as a matter of fact, they manipulate the models, but the model was, are essentially your database. So basically they just made records in may in the database and delete records from the database. They said H to be Heathers. So they, they, they, they deal with output. Even they communicate with external services. They do pretty much whatever you can think of that can be done by your application. And this is how a lot of our responsibilities. So we disk and privacy. And I was, I hope that I have proven my point that that w ABC and the original ABC are, are very, very far away from each other. And this, this has been a known fact for quite a while by, by some people. But I just wanted to point out for the web developers who haven't done any graphical user interfaces, I mean, like a desktop applications. We call them desktop publications now what, what the differences are and in my opinion, and they S NBC and it's regional concept is an applicable for Rab applications, or at least in the form that we do them now. And the web MVC should not be called [inaudible].

So why is it DOE called MVC at all? Now, here we go back in history for some history learning. Okay. We're going back to the 1990s and we're going to take a look a modern language for the word Stein. It was new language. The language is called Java. So Java introduced Java server pages and Java server pages were small scripts that initially, I have to say initially, initially there was most crypts that w basically create an output HTML pages out of templates. So if you have worked with BHB without using a framework whatsoever or if you can work with VHB 10 or 15 years ago when pH before was still a thing, eh, it pretty much resembled, well pH, pH beer example, the way BHP work resembled Java server pages. So you would have some HTML templates and you will have some Java code scrambled in between.

That would be called a script blitz in the Java world and in Dulce files you would have all the logic that you would need, you would have the database requests would have a [inaudible] and then as you would have conditional rendering of HTML and so on and so forth. So, and its initial way of working Java server pages very much resembled PHB will actually is the other way around because BHP is a newer language. So BHB resembled Java server pages. So basically we'll have a request that would go to the server. The server will evoke a job, a server page, a lot of things with happen. A HTML will get mixed up and then some sort of way response will be sent back to the client. And as we know that can get really messy. Now if you notice in the title of the slide, I've written JSP, JSP stands for Jarvis over pages. Mother one, there were not called model one. Initially they were called model two. Later on when model two came about. So what was JavaScript? Oh, Java script, sorry. Java server pages model. It was an attempt, a rather successful one I would say to put some order into the chaos that a complex Java server pages would get.

Because you know, with a, with a very simple page, it is called template thing. It can work out, but when your application gets more complex than then you have a problem. And furthermore, one of the biggest problems that they had was that the people writing HTML had different skill set than the people writing Java. So they really needed a way to separate HTML presentation from the database queries and all the logic that was happening to generate them. So they came up, wait a [inaudible] Waldo too and Motlow to really resembles what we now call embassy later on. We'll see why. So basically the user, the, the HTTP request would be intercepted by something called servlet or a filter and that would later on be called a controller. The serve lip or a filter would do whatever logic necessary based on this request.

And then it will passed some data to the Java server page, which was the good old template from a mother Wong. But it would be, it wouldn't have the responsibility of having any logic in it. So the data from the survey will be passed to the Java server page and then the journal server page would interact it with it, that that would be the job of beings and it would produce a response that would go back to the browser and the Java beans or the model will communicate with the data source and database. And this is just this, pretty much the MVC we know now. So this is, this is how it was born. Original name, JS, Java server pages model two.

So next and next point in history that is very interesting. I've called this slide music without borders. So it was going [inaudible], I hope I pronounce this right, who wrote an article in the magazine Java world in 1999. And the article was called understanding Java server pages model to architecture. So in the case article he was explaining to readers what a, the motto two Wars. And in his article he actually started using the term embassy for Java server pages model too because he found resemblance of the MVC pattern and what model two was. And there was indeed some resembles. But another interesting thing that, that he did, excuse did, he didn't like he gave an example given he gave an example. The example was a music catalog. So the music catalog was called music without borders. And this was, I read the article, probably should have added a slide with some code in it.

I read the article and that was the original Beth gold, the IC, and in all the ambitious applications in, in, in our days. So what he did, he used a vector in B words of vector is simply a memory for a model. And he used that vector to story information about CDs that the user wanted to buy. So the vector was basically the cart of his online music without borders, catalog, slash, shop, and all of the, all of the logic that was handling the requests and manipulating this vector. So putting things in, removing things from that was handled in the controller. So the original implementation, that was it. He defined what have you, was he find what a controller was? Unfortunately, he didn't give a quite good definition of what a model was. So this was free to interpret. And he did all his business logic in the controller, leaving the model with only a vector.

Of course, this caught on, and I guess this is how we get the models to be just a database obstructional era these days. And next year, year 2000, the Apache struts framework who was released and the Apache struts framework that was a Java framework for web applications and it claimed it implemented MVC to MVC. Two stands for the short for MVC model to it claimed that it is implemented to embassy and that it has the architecture shown and disliked. So basically user browser would make a request to a controller component. The controller component though then instantiate a model component. Again, model component there. There was no definition of what a model component was and obviously the Malden bald on foot communicate with the database has, I believe we can, we can get the idea that the mall model component is just a representation of the database and then the controller component with pass the data that it has gathered from the model component to the view component. And then the view component gets sent to the user browser. And this is pretty much NVC as we know it in all languages. PHB will be a Python Django. Well maybe Python. Django is a bit more flexible than that, but I'm not an expert on bed. So Java, this, this, this, this is what, what we use today.

So what are the problems with it? The problems that the Y with, with this type of usage of MVC is all concentrated in controllers. As I said, they, this, this kind of architecture fairly good managers to fairly successfully manages to separate the representation from all the rest of the aspects of the application. But everything else except for the presentation is focused into the controller. So first problem with controllers in web MVC architecture, there is a very poor separation of concerns. And what I mean by that is the, the, the controller has to deal with HTTP semantics. The controller has to know the business logic of a program. The controller has to decide on what kinds of views have to be sent to the user, the controller. He has to know a lot of stuff. As I said before, it, it deals with, with communication to outside services.

It deals with the communication database, although it may happen to a database obstructional area. It's still the controller that does that. It's got it all, literally, whatever, whatever you can think of. It's in the controller. So very poor separation of concerns. And that leads to the fact that controllers are very tightly tied to the environment they run on. And the reason that this bad is I have the fires. I have seen a Cron job making an HTTP requests to the server that is running on the same machine. It's unacceptably Chi. The number of times that I've seen web servers crypt, like a PHP script that is being run on on the web, instantiate a class that is meant to run on the command line is too damn high. Why? Because the, the, this crypts, the, the, the business logic is, is tied to the environment it runs on. And this is not a good idea. If, if you don't see the, the thing that is wrong with a Cron job invoking HTTP calls to the server, it is running on, we can discuss this late. Their on.

So the controller does a lot of things. And that leads also to the bet thing that it has a lot of dependencies. The, the more things a controller does, the more dependencies happen to grow because you know, it does a lot of things and it also becomes really fat. So there is a lot of lions concentrated in methods of controllers because they do all the business logic is in there and that makes them really hard to maintain. And as I said, they even set out the pillars like they deal with output as well as everything they have. You know, it's, it's the view that renders HTML, but it's actually the controller who says the Heather's who's who decides on whether they should be zipped. It makes decision on whether they should be written to file or send to the user. How would you be sent to the user? And so on and so forth.

So in short, this is why I don't like the web MVC way of doing things. No, of course I don't want this to be just a rent. I would like to propose something smarter. And this martyr thing, it didn't come up with it. It's called action domain responder. And it was Mr. Paul Joe's that came up with this and the action domain respond, respond there Potter. And it really it's, it's really, really kind of similar to why MVC if you look at it. But there is some, there, there's some details that make it a lot better. So first of all, it's designed to benefit quant server environments. So it's designed particularly for that client makes a request, a server, handles their requests, server sends a response and that's it.

So the way it works is what we are missing from this diagram is some sort of a front controller or the front controller being realtor. So the router would map a requested routes or something, try and action, the actual getting will be invoked. And the action, it's only task would be to collect input from the to collect data from the input that the input would be on HTTP requests, then invoke a domain object and then pass the data is collected from the input to the domain object. And, and, and, and start running it, collect the data from the domain object. Can we collect data that has been returned from the domain object, invoke a responder, assign data from the request and from the domain to the responder and allow the responder to do everything connected to, to, to output. So sounds very similar to we see. Let's take a look. It's a little bit more details of the differences. So, and action, it's a function or a class implementing the command pattern. So the command pattern, it's basically [inaudible] a single method or class that when vote does something that that's a, it's, it's, it's, it's, it's basically the object oriented, a representation of a function. So this is what I actually is. It does one thing only. It has one action, one method, one function or one method. And it can be very easily implemented by using the invoke magic magic.

As I said before, it collects data from the requests. That's all he does. Okay. And passes it to the domain. So the action should know what data domain expects. And all it has to do is map input data, the domain parameters, then it starts domain and evokes it. It puts whatever is returned in some sort of a variable. Then it creates a responder and the responder can be it can be a specific for this domain or could be some sort of a generic responder. Then it passes some domain data, request data or any other data that the responder needs. So the responder and started their responder, the responder. Then since all output the, the action does not set any optic headers. It does not send any output. It does not care output at all anymore. So it makes it a really, really, really simple thing to do.

It's, it's, it's basically essentially just map input, do two main parameters, get the return value of the domain, put it in that responder. That's it. Okay. So what is the domain? A domain is pretty much it acts as the motto. The reason that Mr. Paul Jones called her the domain was to avoid confusion with with multiple entities or with database extraction layers or whatever. The idea of the domain used to be the entry point into whatever does the domain work. So again, this can be as simple as a function or a single class that implements the command pattern. It doesn't mean that it does simple things or, or, or did it doesn't use other objects or services or whatsoever that it needs afterwards. But the, there, there is one single entry point that is used and that that can be a function that can be a class again.

And the idea behind this is is to I stimulated the usage patterns norm from a domain driven design such as application services or use cases to do, have some sort of a service layer or transactions crypt. That's, that's the point to expose the top level of on the, on the architecture to the environment that the application is being run on. The domain does its thing. The domain can be very complex and it returns some sort of data. The data is passed the responder and then the responder handles all the output that that needs to be handled. It would set cookies would say Heathers it would apply compressions if needed. It would choose the presentation for my threat, it will be Jason or an HTML or a XML or whatever, and then it would output this to the user. So basically this is the end of my presentation, unfortunately.

I forgot to write the at the end and take your slides. So sorry for that. Just as a final thoughts, I have implemented the action, the main responder already trio 4,000, not really. Anyway, treat times, let's say three times and it works very, very, very well with a micro frameworks such as slim or a have also done it with a JavaScript with no GS. It works beautifully with express and I've read a criticism on Asian domain responder that you, you, you, you end up with a lot of classes and in particular with with actions because you see, you have one class that represents that action for every single domain, a use case that you have. But I've actually managed to do not have a single class. They actually, I've actually done it with a very generic class that literally just map inputs to parameters works beautifully.

And my opinion is this is, this is the way to go. Looking direction domain responder makes a lot more sense, especially if you're familiar with a omnium or hexagon or architecture works on adopters. It's three names for the same thing because we're really bad at giving names and we proves it. It's, it's a lot better way to do stuff, in my opinion, Fordham or it can be expanded to something that resembles real MVC a lot easier than what we have now. But that's, that's a topic for a totally another talk. So pretty much, pretty much, this is what I wanted to share with you this evening. And just as a final thing to say, Mr. Paul Jones, the altar of action domain responder, you will be able to hear more details from him. You'll be at Bulgaria PHB conference. So join us. He has stuff to say.

He has been one of the founders of BHB fake. He, he's an amazing guy. I'm really excited to have him over. And pretty much that was it for me. I hope that I have at least made you think about whether or not to continue using this pattern. Truth be told, modern frameworks allows, allow us to, to do, do not use MDC and, and, and have our applications with it modeled in a better way. So let's, let's do that. Let's do that. That it, it would make me and a lot of key these KPIs. So thank you. Thank you for a patient.

Milko thank you for a, a tremendous presentation and explaining kind of the history of MVC and the challenges of VC while also bringing up you know, the action domain responder model. You, you mentioned you've integrated yourself three times. Have you seen it implemented? Any other types of applications or any of the types of frameworks that are being used on the web today?

No, actually, unfortunately, no, actually, but unfortunately I haven't you know, I've, I've, I've implemented this with Greenfield projects and it was, it was super easy to implement, didn't need any particular frameworks, especially the first time I implemented it. We, we had to, we had this project that was based on WordPress for whatever reason. I mean no offense to WordPress. This was just the project was, was was something that was not supposed to be built with WordPress. So we, we're trying to escape from WordPress. And this, this way of work really, really helped us because what we made was just map WordPress actions to, to do actions in the terms of action domain responders and the responders would then make a fix the gap with w w with, with communicate again with WordPress and our domain had nothing to do with WordPress. It was, it was beautiful.

It was so easy and so clean. I love it. And this also allowed us to test our domain in a lot of ways. Testing what WordPress is, something that is not, not easy, but because we, we managed to do this in such we managed to separate our own code from WordPress. We could do and do testing on it easily. And then the actions and the responders, they would be the bridge be between WordPress and us. It works beautifully as I said. And the rest of the times I've done it two times with express with no GS. So slim, I guess in a lumen working frameworks like that, they would, they would also work perfectly because with them, you just, you just need to pass a single function. And that would be your action and your action map the door, the request to two parameters of another single action that would be the domain. And then from that point on, you can, you can, you can do whatever. And because the domain doesn't know about HTTP requests or cookies or sessions or whatever, that's the point that domain shouldn't know about them. You can reuse your domain in a command line script. Can you reuse it? Websockets well we PHP the regional where you use for graphical user interface, but you're ethically, we could if we had this libraries. So this is why, why I love it so much because it's very well separated

In terms of concerns. Perfect. is there a use case where you'd recommend using MVC over a ADR

In, in, in, in graphical user interfaces. But no in, in, in terms of MVC the way we're doing it now, like the model two? No, definitely. Well, this was a step forward, but it was not enough, so, no, definitely there is, there is, there is no, no, no, I wouldn't, I wouldn't recommend using MVC model to MVC instead of ADR in Norway.

Okay. when transitioning from MVC to ADR are there any challenges or caveats or, or tips to give people as they make that transition from one to the other?

Well, if I have to be honest, I haven't made a transition. I mean, I haven't poured it an application from a VC to ADR. I have only done it, they would Greenfield projects, but what I guess what I would, I would suggest it's, it's, it's actually, it should be actually really easy. So what if we, if we're talking about refactoring from MVC to ADR, basically all we need to do is get the cult from your controller action, put it in a separate class. Remove everything that says HTTP that has to do with cookies, requests, parameters, false, whatever. Keep this in, in the controller, map this to parameters of what do you hit, copy, paste it. Gold is your domain. It will be fat and ugly, but it will do for now. So that will be step one, step two in the method that you keep just refactored created as a separate class. The, the refactoring should be really, really easy.

Okay. Another quick question for you actually a couple more. And this, it seems like the idea of ADR is a really good idea, but it's never really gained popularity especially in the FinTech space. In your opinion, what's preventing wider adoption of the action domain responder? A approach?

Quite frankly, no idea. The only thing I can, I can, I can think of is that it, it requires people to, to make the so-called separation of concerns and this, and this is actually rather hard. It's a lot easier to count a request and then start looking, inspecting the, the request and just take actions and like, I mean in, in terms of top process then to say, okay, this is an input parameter. I have to map it into here and I have to somehow extract some sort of dating or from, from the domain which in which you make a decision on the view. I mean, the only explanation that I have is that it's beef harder because you have to, you have to think about what is, what this is. This is the only explanation I have. I have no other ideas. Why, why would, would that be? Okay.

And then for those that want to start bringing ADR into frameworks, like letter boy, I know there's a couple of great articles out there on this already, but do you have any tips or suggestions or resources that can help them as they try to implement ADR in to the popular frameworks where, or a puppy or packages out there?

[Inaudible] No, but no, no, quite frankly not. I, I have, unfortunately not. I can, I can about ADR, quite frankly, the only articles that I found, the only materials were from both Jones himself. And as I said, I don't know why just didn't call up nobody was trying, but, but the concept is very, very simple. I was thinking about actually implementing it for the third time. I was thinking actually really make a package or express to, to do this stuff. But then I realized, okay, the code for this package, it's like five lines. So I mean, in order to get to from, from express for those not familiar with express, it's pretty close to women and slim. So it, it would take me literally five lines of gold to get from whatever framework entry point of framework, which would actually remain responder.

And so I give up line eight on the idea cause I was like, well, why, why, why bother? Really? Why bother? And maybe, maybe, maybe that would be it for the more packages in terms of packages, they're like, why, what kind of packages if, if, if we're talking about a library, well the library is just a library doesn't need to follow any, any, any sort of a concept like MVC or ADR. You just use it in your app. You're injected in your app somehow and you use it. So this, these are concepts that are applied to your application. They do not apply to a package. So I guess that would be my answer to this question. Okay. Two more questions that'll, they'll stop bugging you here. Please go. For those that want to learn more about ADR, do you have any resources you'd recommend? Them reading or looking at? Yes. As I said, there's literally only one. Okay. Maybe it would've been a good idea to let me escape. So if you look for extra Romanian responder in Google, what you would get first is the Wikipedia page and then you'll get Bojangles' get home. So the Wiki video page links to pole jaws, get cups or just go there.

This is the only resource on ADR that I have so far seeing it's it's, it's very well written. It gets it communicates the idea of very nicely. It's it is very well motivated. So you will not only read about what ADR is, you'll get the idea of why, why it happened. Well problems it solves. You get a very nice comparison between MVC and ADR. You get what a, the tradeoffs for ATRs. Are you even there? She, you [inaudible] written some objections to ADR pretty much this, this, this is like 100% of the documentation and it's very, very extensive and it's, it's, this is the way to go. I haven't written, I haven't read anything. Anything else? I haven't found anything else in the web about this. Again, I don't know why. I guess it didn't call off. I don't know why.