Implementing the Clean Architecture


The application



A family of architectures


The Clean Architecture












Lesson learned: bounded contexts











Clean Architecture + Bounded Contexts

Lesson learned: validation









Closing notes




Further reading

Sign up below to receive news on my upcoming Clean Architecture book, including a discount.

Other things to look at:

39 thoughts on “Implementing the Clean Architecture”

    1. Hey Dmitriy, that’s a good question.

      We did not move the presenters to src, but moved the contexts out of it. Still, the question of why we did not put the presenters together with the associated context remains valid.

      We decided to limit our contexts to things bound to the domain model. That means the outermost “layer” of the contexts are the usecases, and that they remain fully framework independent.

      From the literature I figured that what you suggest is the more common approach. Indeed we discussed reorganizing our codebase as such, but no compelling arguments where found that justify the effort.

      I raised this question on the DDD CQRS list when we where talking about this in out team. Unfortunately we did not get any reply.!topic/dddcqrs/tWc6iZGhvUU

  1. This is a fantastic writeup. It’s very nice to see that the Silex actions are almost point-for-point examples of Action-Domain-Responder . (Some of the actions might do with trivial refactorings to bring them even more in-line with the pattern, but overall it’s very well done.)

  2. A longer reply here:

    An excerpt:

    “The only place where Jeroen’s implementation deviates from ADR is that the Action code builds the presentation itself, instead of handing off to a Responder. (This may be a result of adhering to the idioms and expectations specific to Silex.) Because the rest of the implementation is so well done, refactoring to a separated presentation in the form of a Responder is a straightforward exercise. Let’s see what that might look like.”

  3. First, great article. I am a big fan of DDD and UncleBob both. I took the time to clone the git repo so I could browse it in PhpStorm and was really enjoying going though to see how you did the separation of concerns and boundaries etc. Then I came across … please explain, what the heck happened here???? there are 160 use statements at the top of that 1000+ line file … It looks like a dumping ground. Though I realize I am, it is not really my intention to be critical. I found this article searching for good examples of clean architecture in php and was happy I found your article.

    1. Hi Todd. You are right that this file has a lot of lines and many many dependencies. It is the top-level factory of our web application. It is the wiring where we inject the dependencies of our classes. This is single responsibility. And even though there is a lot of code, it is rather flat and uniform, making it easy to modify. We *could* split the top-level factory, though I suspect we’d be making a bad trade-off. Having a big top-level factory (or equivalent DI mechanism) is, as far as I am aware, not uncommon and typically not considered a problem.

    1. Hi Norman! There is more than one answer to that question and it depends on which code exactly you are taking about.

      In this codebase we have some instances where this architecture rule has been violated where it should not have been. If you search for TODOs you are likely to find some of those. These violations where created due to our lack of experience with The Clean Architecture. The ones that remain are not high priority issues, as long as they are not made worse, and hence likely will stay as they are.

      There might also be cases where we deliberately made an exception to this rule. There definitely are route handlers that use services directly rather than using a UseCase. If the UseCase just takes argument set x and passes it along to some service taking the same argument set, and thus not containing any application logic, having it is not necessary (and possibly harmful).

      1. Thank you for replying! (in such detail, too)

        That explains everything and answered my question! (also confirming my assumption, why certain decisions were made). It makes sense, to not use a “useCase” if it is simply delegating simple data-sets! 🙂

  4. That was a very good read about clean architecture. That’s the first time I see multiple DDD bounded contexts in action and it is nice. Regarding the previous comments, where controllers reuse directly domain service instead of using UseCase, well it’s a tradeoff, I faced similar situation and I don’t think there is a right answer, sometime it doesn’t worth it to add delegate boilerplate. Accessing directly the domain from low level is not a big issue as accessing directly low level from domain. Very good job, your codebase is a reference.

  5. Why are you so firm that outer layer could only access one layer under them?
    Why View layer (controllers) can not have access to Domain Entities?
    Uncle Bob’s Dependency Rule says only that nothing from outer layers should be used in the inner layers.
    Your restriction is not mentioned.

    1. Hey Micheal. I also mentioned this restriction in this post though likewise did not explain it much.

      I got that idea from Uncle Bob. Since this is quite long ago I do not remember where, though as far as I recall he mentioned it in several places.

      The basic idea here is that there should be no logic in the presentation layer. And there should be no presentation concerns in the domain model. Without the boundary that is formed by the Use Case layer, it is easy for such violations to happen. By having the Use Case layer as a boundary you also get a nicely defined public API to your domain model. Refactoring the model is a lot easier if only the Use Cases use it rather than also any number of presentation concerns, possibly in different applications.

  6. Hey guys,
    You’ve done a great job and I would say that your project is one of the best PHP + Clean projects which are available online. Additionally you put a lot of effort into the BC separation – something that is completely missing in the hundreds of “clean” projects around. The presenter part is also visible and well thought. So … gut gemacht 😉

    Do you have any plans to get rid of this spaghetti class any time soon?

    I am pretty sure you can organize this much better.
    The other huge file – FunFun – unfortunately it is too late to fix it but just as a suggestion – there is the “Pure DI” which could have probably fit well into the project.

    Anyways, excellent job one more time!

    1. Hi Marian! Thanks for the kind words.

      I would not classify either Routes.php or FunFunFactory as spaghetti. Yes, these two contain a lot of code. Yes, they contain a lot of things that could be separated. Most of the time that means there is a problem. However for these cases the code is (1) highly uniform and (2) highly independent.

      If you put the code from Routes.php in dedicated files, the structure would not change. The benefit would just be that you have one route per file. And not a clear cut benefit at that. Having things in one file has its upsides as well. We did put a number of routes in dedicated files because we “needed” dedicated classes for them.

      You could double the size of FunFunFactory and it would make essentially no difference. Same goes with reducing its size 10x. I used this top level factory approach in many projects and find working with one that has 5 methods just as easy as one with 500. Using a DIC (like you have in Symfony for instance) has its ups and its downs. I’m not convinced it is the better approach, so I tend to default to the simpler one used in this project.

      1. Hi Jeroen,
        Thanks for the quick reply 🙂

        I noticed that you have controllers for some of the actions and I assume that it depends on the controller complexity. Still I would prefer to keep the “entry point” of a PHP application as short as possible since every request should go through it. I know that we have OpCache which works quite well but I think it is nice if we could pass the control to the specific code as fast as possible.

        For the dependency injection I meant just using DI but not necessarily with a DI-Container. I know that it is quite convenient to pass the big “bucket” to every controller so that they can ask for whatever they want (and therefore transitively depending on maaaaany classes) but the other approach is that every controller specifies the dependencies it needs and they are passed as constructor arguments by the responsible dependency provider.

        P.S. I hope you don’t get my comments as a criticism. I myself try to build a similar clean solution and I just see how common our problems/challenges/decision points are 🙂

Leave a Reply
