Generally speaking, what is a Domain folder? What does it mean/contain? - php

Lately I have been looking at a lot of different php frameworks and various php packages. Whenever I first look at project, like said frameworks or packages, I try to digest it's directory structure to get a clue as to its organization. I've noticed that there are often reoccuring themes, like an "app" folder, a "tests" folder, a "src" folder, a "var" folder and so on and so forth. Usually I understand what these folders represent or mean, however lately I have been coming across a folder I do not understand in project directories: a "Domain" folder.
What does a Domain folder represent? What kinds of logic or code are contained therein? Does it have any relation to an actual Domain name?
Any and all input would be greatly appreciated.
EDIT:
To provide a specific example of what finally prompted me to ask this question, I was looking at the starter boilerplate that is generated by the php "slim" framework. You can generate this project by using php's tool composer and running:
composer create-project slim/slim-skeleton [app-folder]
Here is a link to the repo on github. Within the "src" folder of this project, there is a "Domain" folder. At least for this specific example, what does the Domain folder represent?

"Domain" is the main term in DDD (Domain Driven Design) architecture. it has many concepts to learn but in summary, we can say that the Domain section is the core section of your application logic and it contains your domain models and their services like factories and model validations. I suggest you read this reference, it can help you to comprehend DDD concepts.
https://martinfowler.com/tags/domain%20driven%20design.html
Edit:
In your example which you mentioned, as you see there is a "User" model in the domain section that there are some of their services like exceptions or interfaces of its repository.

Related

ZEND Framework folder/file structure

I'm trying to learn zend framework. I managed to install it on my localhost. However i'm having trouble understanding the folder structure? There are 5 main folders after installing the skeleton application - config, data, module, public and vendor.
I've seen some proposed folder structures online, but how to I go about it? Do I just create folders like views, controllers, models etc?
Thanks!
Vendor is where composer installs dependencies and libraries, config is where configuration lives, data is for cache etc, public is where your index.php and css/js/img assets are, you are really interested in module directory that contains application modules. For the start you only really need one module - Application, inside this directory you should have config dir that has module specific config, Module.php - module bootstrap file, view with templates structured per controller and src folder with your code. Inside your src file there is your Application module namespace directory that is placed in Application directory to mimic PSR-4 autoloader namespaces it can contain your application code in this example directory structure: Controller, Form, Model. Model can contain Service, Repository and Entity folders
If you just got started with ZF2 I suggest reading some documentation. Basic things like this can all be found in the documentation. For example here you find more about the folder structure.
I would also suggest taking a look at the ZF2 Skeleton application documentation/tutorial since this will help you understand the basics of a ZF2 application. Here an example on how to structure a new module. Building the album application yourself is a really nice way to get started.

Directory structure in MVC PHP Frameworks

At this moment, my framework's directory structure looks like this:
framework/
libraries/
autoload/
autoload.class.php
resource.namespaces.php
router/
tests/
router.test.php
router.class.php
resource.routes.php
configuration/
framework.configuration.php
router.configuration.php
controllers/
index.controller.php
models/
index.model.php
views/
default/
index/
index.view.php
header.view.php
footer.view.php
assets/
css/
javascript/
images/
index.php
When my framework was smaller, it was a lot cleaner. I have give a look at other popular frameworks. They have two main folders:
framework/
app/
web/
Actually, this structure is very clean and nice because we separate the front-end and the back-end. But I wonder what should I put in each of these.
Logically, libraries folder should be inside the app folder, but it is not really a part of the application. For me, an application has models, controller and views. I think libraries should be put outside. Where should I put my libraries?
I has a lot of PHPUnit tests in my libraries. Should I add a folder named tests inside each library, or should I put it inside/outside the app folder?
If I want to implement a template feature, where I could choose which template I want to use for my website, how could I organise it? Every template has differents elements, so header.view.php will not be the same, etc. Now, I'm creating a folder in views which is the template folder. But I think it is a bad idea, 'cause now, for every template I must recreate all the views.
In a lot of applications, there is a vendor folder that contains all the main classes. Is this the same as my libraries folder? Does it have the same role?
I also have some 'resources' files (eg.: resources.routes.php). They are used to add some routes/namespaces. It's a bit like a configuration file. Should I create another direcotry for these files, or put them inside the class which they refers to?
I'll try to cover all your questions.
The vendors folder that you see in many apps is from composer. In that folder are all the dependencies of your application/framework (often libraries from other people).
Composer allows you to pull in some good components for your framework so that you don't have to write everything from scratch. Say for example I want to use FastRoute because it is much better than any router I am capable of writing myself. So I just add the following to my composer.json, run composer update and I can use it in my framework.
{
"require": {
"nikic/fast-route": "dev-master"
}
}
You can also use composer to autoload your classes so that you don't have to write your own autoloader (and cache that for production).
I really dislike your current file names. adding .class to a filename makes absolutely no sense to me. The dots also just complicate Autoloading. I recommend you have a look at PSR-0 for some inspiration on how to handle file names/namespaces (This is supported by the composer autoloader).
For the tests you could create a Tests folder in the root folder of your project and in there recreate the directory structure of your project and add the test classes in the matching folders. You can also put your mock objects in there. This makes it easy to just run tests for a certain part of your application.
I also recommend that you move your application out of your public folder and instead have a public folder with only an index.php and your assets. That index.php does nothing other than requiring your front controller that bootstraps your app. Doing it that way adds another layer of security if for some reason your webserver stops processing PHP. Otherwise a visitor would be able to see your whole source code.
To get some inspiration for your folder structure questions, I recommend that you have a look at how other people solved this issue. Arya and PitchBlade would be a good starting point because they are way smaller than a framework like symfony.
I hope this helps. In the future I recommend that you split up your questions into different SO questions, that makes answering easier and you will get better answers because people who know the answer to one of your questions don't also have to answer all of them.

Project structure for PHP

I am new to PHP and want to know the directory structure for the php projects. I have experience in Java and in java we have src contains java source files, WEB-INF contains lib, and jsp pages. Do we have any similar standard directory structure in PHP?
Also do we have layering in php like we have layers in java (e.g. Web, Service, DAO layers)
I browsed few links. But every one giving different answers.
Not sure if we can compare the two languages. I just want to stick to some standards.
Thanks in advance.
Nope. PHP is what you make of it. It can be very simple flat files, or however you want it.
That being said, there are a few agreed upon coding standards, but there is no "enforcement" of said standards. They are called PSR (PHP Standards Recommendation). There is a background on it here: http://net.tutsplus.com/tutorials/php/psr-huh/
You can view the standards one by one here: http://www.php-fig.org/psr/
Most major frameworks follow these standards, and if you are going to use one, it may be easier to go with the flow.
Again, every framework, project, plugin, program, etc, have different layouts with different project structures. A common structure is something like this:
-framework_dir
-public_html
-js
-img
-css
-index.php
-protected/private
-controllers
-models
-views
-etc
They then use the .htaccess file to block access to the protected directories. Again, this is just the common representation I have seen in several frameworks. If you are doing a personal project, just use something that is comfortable to you. Every framework is going to give you a different library or way to access the data. There are no "layers", but again every framework has objects that handle different areas (email, database, cache, http, logs, etc). Because there are dozens of popular ones, it is just up to you to find what fits with your philosophy or project. Watch a few of the 5 minute blog videos, see what jives, and then give it a test run for a couple days. If you don't like it, switch to another.
With the invention of Composer, people now have a central place to register their projects for the world to consume, and other people now can look at that code base and see similarities.
The result is this: https://github.com/php-pds/skeleton
In short:
If a package has a root-level directory for
then it MUST be named
command-line executables
bin/
configuration files
config/
documentation files
docs/
web server files
public/
other resource files
resources/
PHP source code
src/
test code
tests/
This standard does not make any further recommendations about which directories have to exist below src or public.
The task to organize your PHP source files inside any of these directories is still up to you, but there are suggestions outlined in this article that I'd agree on: Either sort by type (controller, entity, service), or sort by feature (user, login, cart, catalog, article, comment) - the latter keeping all the code that belongs to one feature in on directory (or few sub directories), which often seems to be the better file organisation.
When organizing by type, you'll find yourself jumping between directories quite often, and also you do not get a good overview about what the code is about - you'd always have "Controller", but you rarely have "StampCollection".
I tend to use a Feature-based folder structure for my backend projects.
Every feature-folder has his own controller, manager and routes file. This works well for api-backends. It looks in a way like https://blog.nikolaposa.in.rs/2017/01/16/on-structuring-php-projects/
For example, we have a Customer feature with a CustomerController, CustomerRepository, CustomerRoutes,..
My folder structure looks like this:
- build/
-- phpdox.xml
-- phpmd.xml
-- phpunit.dist.xml
- config/
- public/
-- .htaccess
-- index.php
-- assets/
- src/
-- Customer/
--- CustomerController.php
--- CustomerRepository.php
--- Customer.php
--- customer.routes.php
- tests/
- vendor/
composer.json
.gitignore
Unfortunately (or not?) you're very free with PHP. It's up to you.
Here's my structure:
framework/
controllers/
models/
configs/
files/
templates/
themes/
tmp/
index.php
init.php
.htaccess
You can control the access via .htaccess.
For a library, I am using the following structure... plus i've included recommendations I'm not using (yet)
PROJECT ROOT
|--composer.json
|--README.md
|--docs //for documentation files
|--tests //for Unit Tests
|--vendor //for external libraries (if everything isn't included through composer)
|--examples //examples of the library being used
|--config //any configuration files you may have
|--src //where the library's actual code "lives"
|--php //php source code, classes, any other scripts
|--View //html views, but actually php files that output html
|--Style //contains .css files
|--Script //contains .js files
|--Res //contains other deliverable resource files. Could be mp3 files, json etc
Currently, I'm only using composer.json,README.md, and src among the root files. But I will probably use the others as I've described, when i get to that point.
By no means do I think this is "correct". And this setup only works because I have a php router on every request. With a .htaccess, you could route a .css file to /src/Style/requested_file.css.
I wanted the project root to be cleaned up, and I have achieved that. PHP Fig does not have a PSR for directory structures... that I'm aware of. I had hoped PSR-4, autoloader would have had some standards, but... not really, in regard to directory structure.
You could look at laravel, wordpress, PHP Mailer and other php libraries to see examples and see what you might like best

Code reuse in PHP framework between multiple projects

This is my first question here. :)
I am working on a little php framework and started to think of ways to re-use the same code between multiple projects. Right now with this framework it is possible to make multiple application directories for different projects and use the same core - similar of what codeigniter 2 does.
The question about code reuse raised at work when I needed to make a website that is quite different from existing one, but would still use classes from it.
My first two ideas was either use some kind of a global "models" directory where to place files shared between multiple projects (and add option to framework to load them), or to add a possibility to load these "models" from other project(s).
I thought maybe somebody else have some better ideas and wanted to know other developer thoughts on the subject in general.
As an example this could be the current directory structure:
live/ - live site
config/
controllers/
helpers/
models/
public/
views/
admin/ - administration (same structure as "live/")
system/ - framework core
Well I don't think loading models or other classes directly from another project is a good idea. If two or more projects share the same classes, they should be located somewhere outside of both projects. This is the situation where the codeigniter packages comes in handy. It allows to have separate folder for all of your libraries, models etc. and load them in any codeigniter project very easily. Take a look at the official documentation for more details.

Best practices for php project organization using GIT?

I'm working on releasing a PHP framework I have been using for a few years
on github. Been trying to read up on the most correct way a project
should be structured, what extra files such as readme's etc should be
added. Been coming up with blanks on google. Can anyone point me to a
project that's a good example or any good write ups.
Some PHP projects hosted on Git(hub) include:
CakePHP
Gallery3
Garden
PHPUnit
Kohana
I'd just make sure that no temporary files, etc. get in the repository by creating a .gitignore file, and add some readme's etc. to the root of the repository.
Any configuration files should also be ignored, and sample configuration files should be created in the repository.
I'd recommend writing the readme file in a format that Github supports, like Markdown. It'll make your repository front page look better.
You might want to follow some kind of class naming guideline to make things like autoloading easier to implement. For example, the class MyFramework_Controller should be located at directory /lib/MyFramework/Controller.php.
You should just create some kind of basic layout for now - it'll be easier to give suggestions when we can see what you have right now.

Categories