Basically, the question "how does a user log in?" is very rarely a part of your domain. But the question "is a user logged in?" or "does the current user have permission to do $someAction?" is a part of your domain.

A good way to figure out what is or isn't part of your domain is by asking a question and then think about how likely it is that your client would ask that same question.

@thepsion5 some times the authorization process is part of the application domain . as example in crm application the user is employee in the company and have specific role . how about this ?

Hi @AlnourAltegani, then may need to segment your logic between the Application Layer and the Domain Layer using Application Services and Domain Services. The first type as ports that gives you for example access to Authorization using any OAuth way, and the Domain Services for manage the Domain Classes (User, Permissions, Roles, ...)

I think that depends on your needs and there is not an unique way to make it.

@AlnourAltegani See my previous reply and what @codeatbusiness's post above mine. I consider Authentication, IE "are these credentials a valid user?" to be an application-level concern. But Authorization and Access Control, IE "does this user have permission do do X?" is a domain-level concern.

@thepsion5 @codeatbusiness Ok cool, thanks for the answers :) Can you please provide a quick example with a folder structure so I can see if I understood it right? I am new to DDD so I am still learning stuff about it and how it works in detail.

Wow this is great :P And @thepsion5 I really like your ideas about structure, I'd really love to see a more in-depth article about it ;)

@thepsion5, thank you for sharing your folder structure. Any suggestion on where you would put your middlewares ?

@RayRutjes are application specific classes

Aren't they kind of Http related as well ? You would put them all in the App folder ? Under a Middleware folder ?

Middlewares would go in either the App or Http namespace. If you're using one to do business logic, however, it shouldn't be doing any of the logic itself but calling a class in your Domain namespace.

Thank you for the quick answer. I agree with your point of view @thepsion5

@thepsion5 is there any chance that you could possibly put together an example repo. Noticed that a lot of questions are asked all over the place and it'd be great to have a central location to see the layout (especially with things like the middleware from above or the ACL from https://laracasts.com/discuss/channels/general-discussion/l5-folder-structure-best-practice).

With your repositories, do you have an Infrastructure layer abstract repository with the standard things in (get(), all(), etc.)?

@thepsion5 I like your structure pretty much and I read a lot about DDD in the past weeks. From my understanding there are services on the domain and application layer. And a domain service has a different definition than an application service. I only can find domain services in your example structure.

Where do you put application services? A solution would be to have one folder per module in the app/ToDo/App directory, too. But then we would mix module folders with other folders like Providers, which i personally don't like. Or do you just see the controllers in the app/ToDo/Http directory as application services? Thank you! :)

@thepsion5 thanks for the valuable information in this topic.

I know it's been a while but I wonder if you might elaborate on how you wire this sort of folder structure up with a new L5 application. Do you remove a lot of what is there and update the references to the default folders, or do you leave it as is and just add things on top?

@nztim @jeremyihrs @Koga I've recently had a chance to work on a "real" project with Laravel 5, so I'll try and get an updated post plus an example repository going in the next week or so. :)

Thanks @thepsion5, looking forward to it!

@thepsion5 That would be great..

@thepsion5 looking forward... its been 4 months :-)

@thepsion5 could you make a dummy structure and github it sort of a boilerplate for DDD?

I'm sure that @thepsion5 gets a ton of requests for this "structure" repo, so I thought I'd share a few resources that have helped me get up to speed w/ DDD in PHP:

Implementing Domain Driven Design by Vaughn Vernon - Written with examples in Java and does a fairly good job of explaining techniques and concepts while providing a lot of tactical examples. Some sections are not as applicable due to their reference to Java libs such as Hibernate or Spring, but if you can read a method in Java, you can follow along pretty easily.

Domain Driven Design by Eric Evans - The "Definitive" bible on DDD. I'd say the #1 value here is that it's so focused on concepts. If you have the time, read it before Implementing DDD, it makes it a lot easier.

Domain Driven Design in PHP - Not yet finished (about 70% as of writing this), but it goes over all the core concepts except Aggregates currently (which is what they're working on) and integrating subdomains / bounded contexts. The Modules chapter is very concrete when it comes to sharing how aspects of the project are organized. Non Laravel specific, but often Symfony based, so many similarities.

Building a Web Application From Scratch - An excellent, though dated at the beginning, example of DDD in action. Culttt is a great resource, and he goes out of his way to clearly explain concepts.

laravel-ddd - For Laravel 4, but the concepts translate if you look at the structure. They are very similar to what @thepsion5 has posted in his opening entries.

While the initial examples are amazing, it wasn't until I had really gone through the rest of the resources above that it all started to make a lot of sense.

At the end of going through all of these resources, it's become much more clear to me that DDD is mostly a way of thinking, and letting business language (or the Ubiquitous Language) drive the design of the software. In many ways, it's a business+linguistics first approach, instead of a technical one. If you're serious about the DDD structures, the laravel-doctrine package is very useful for implementing the Data Mapper pattern which is more DDD oriented, and laravel-uuid is another convenient package to use.

Hello folks,

I built a DDD generator and Example Application with Lumen 5.3 and Doctrine. Future releases will include, unit tests, infrastructure service and cross domain operations.

https://github.com/davists/Lumen-Doctrine-DDD-Example

https://github.com/davists/Lumen-Doctrine-DDD-Generator