Hi... this is not a problem. I have just a question for best practise. I just think about where to place my controllers. I have an app which shows price tables. For the page where the tables are show to the user I need a route, controller and a view. The pricing is dynamic, what means that also other package code is needed to calculate everything. ... would you put the routes, controllers and views into your App (app/HTTP/Controllers) or in your Domain (src/Domain/Pricing/src/Http/Controllers)? What is your way to do it?
@pixelairport It seems you might need to read up more on DDD and get a little more familiar with the concepts and its terminology.
A HTTP controller belongs in the application layer. The domain layer is business logic and should know nothing about how that business logic is being used or consumed at all. Your business logic should be isolated and be able to be used in a HTTP context, a console command, or any other I/O environment.
Thx @martinbean we already did this. We already split domain code and application code. But i just ask myself a lot of time, why not to put also views (components) and routes (show pricing) into that,? And when Im working on the pricing, it would be easier to have all in one place. I mean more like a package when I use composer. But ok we will leave the code in our application. thx
PS: What I dont like is that the files are not in one place... I bought a spatie video course, where they say to also have a extra App folder (not the main one) to seperate the application code, if i understand this right. I have to watch it again. But maybe i just need another way to structure my application code. Dont like thousands of routes in my web.php... Maybe work with include or with extra packages... But thx for your help @martinbean
But i just ask myself a lot of time, why not to put also views (components) and routes (show pricing) into that,?
Because how data is presented is not business logic. That’s application logic.
The Domain layer is for business logic only. How a user interacts with your business logic should be in the Application layer. The Application layer calls logic in the Domain, and returns responses. The Domain does not care how and where it is used.
@martinbean thx ... i understand the concept (i think), but don't like it right now. But I think the problem is not DDD, the problem is the structure of my application code. I will read a lot more about it later when i have time. Thx
@Pixelairport If you’re following DDD properly, you should have a directory structure that looks similar to something like this:
/app
/Console
/Commands
/Http
/Controllers
/src
/Domain
/DomainOne
/Entities
/Repositories
/Services
/DomainTwo
/Entities
/Repositories
/Services
Your business logic is completely isolated from any code that handles a user’s request and returns a response. Your classes in your domains should know nothing about controllers. Your controllers should just call logic from your domain classes and return the results as an appropriate HTTP response.
@martinbean thx. I understand this and it sounds ok. Domain is a bit like a microservice but in a monolith and sometimes (if it there is no other way and saves me a lot time) the domains can easily talk to each other. That is why I startet with "It is not a problem" ... I just brainstorm how to structure my code better. Maybe this way:
/app
/Console
/Commands
/Http
/Controllers
/Subscription
/Pricing.php
/src
/Domain
/Subscription
/Entities
/Repositories
/Services
or this looks better for me:
/app
/Console
/Commands
/Http
/Controllers
/src
/App
/Dashboard
/Controllers
/Main.php
/Providers
/routes
/web.php
/views
/main-dashboard.php
/composer.json
/Subscription
/Controllers
/Pricing.php
/Providers
/routes
/web.php
/views
/pricing-table.php
/composer.json
/Domain
/Subscription
/Entities
/Repositories
/Services
And then i have also my app code sorted into parts of same group. Thats what I mean with "Maybe structure could be better".
@Pixelairport That’s not DDD, though. That’s just carving your application up into arbitrary “modules”.
Yes... that would be the better name for that :) Sorry for wrong name. I will check a bit in my next projects what is the best solution for me. But I like the way to use packages instead Domain, when the package can be really modular like pricing. Maybe I have to build a package and then use the package in my application, which also has a domain for pricing and does the rest... i will see. But really thank you @martinbean to talk about it :) Helped me to think about everything again.
Please or to participate in this conversation.