Which grouping should i choose for folder structure?

Hi @stefanbauer, what is the difference between the Repositories of each entity and the Repositories that you have in your Core folder or namespace? Are the last the implementation and the Entities Repositories the contracts?

I usually use something as follow:

appName/Domain
appName/Domain/Entities //If you are using Eloquent ORM put here your models
appName/Domain/Services
appName/Domain/Contracts //Here you can put your repository contracts
appName/Domain/... //anything else
appName/Persistance //you could call infraestructure or another name
appName/Persistance/Repositories //Put here the repository implementations
appName/Application/Services
appName/Providers //Put here your services providers
appName/[core laravel folders]

Hope it helps you

Hi @codeatbusiness, thanks for your reply. Well: My folder don't represent an entity. I would put there in anything which is related for e.g. to addresses. Could be the address itself, contact persons for an address. Everything that is address related. For the "Core" folder i would put anything in which is not related to the things which are already there. For e.g: I have some "resource" Tables, which just returns some data, for e.g. all cities and streets here in germany. I wouldn't know where to put that. Thats why i thought i would create a Core folder.

PS.: What is this "Domain" Folder?

Ok I understand well right now.

Your folder structure is portable for another possible project then.

I usually put my repositories implementations in the infraestructure or storage layer because they don't need to be accesible from the Domain Layer only will be used from the Domain Layer the Repositories Contracts for manage the link between storage and the entities to persist.

The domain folder is to maintain the Domain Logic of your project:

• Entities (Example of a Invoice)

• Aggregates (Example of an Invoice that may contain Invoice root Entity, InvoiceLine sub-entity or another value objects within it)

• Value Objects (Example of an Address)

• Domain Services (some people use it or use directly from the Application layer, it would be a BankTransactionService)

• Contracts (Example of InvoiceRepository interface)

The domain services are services that doesn't belong to a specific Domain Entity.

Using the interface contracts within the Domain Layer you may put injected into your Controller and using then the Infraestructure implementation of those contracts with the IoC container binding capabilities.

Thank you very much for your reply. I still have some questions:

a) So you group them by "what there are" and not to "functionality", right? b) Value Objects can be the same as an Entity? c) Aggregates are also "only" Entities?

Hi @stefanbauer,

The Entity is as you use your Models into your application.

An Entity is a class that has identity, and this is used to manage it and trace in your application.

A Value Object is a type that doesn't have identity and only depends on its attributes.

The aggregate is a group of entities or value objects that compose a big group. This group have an entry point that would be a Entity Root, and it is the only way to manage subentities or value objects within this aggregate.

When you use repositories with Entities, Value Objects or Aggregates, you need to have One Repository for Entity or Aggregate. If your entity doesn't belong to an Aggregate then you can use a Repository for manage it, but if you have a Entity that belongs to an Aggregate you need to access in the Repository only using the Entity Root.

Maybe results a few an abstract concept but, I put an example before that could be useful for understand how works.

Hi @codeatbusiness, thank you very much. Everything clear now! You made my day ;-D

You are welcome :)! I'm learning about DDD, Command and Event, patterns, and so much, and securely some Laracasts users and @JeffreyWay, get a full better answer than mine, but great it helps you.