Download the PHP package inklabs/kommerce-core without Composer

Zen Kommerce Core

Introduction

Zen Kommerce is a PHP shopping cart system written with SOLID design principles. It is PSR compatible, dependency free, and contains 100% code coverage using TDD practices.

All code (including tests) conform to the PSR-2 coding standards. The namespace and autoloader are using the PSR-4 standard.

Description

This project is over 62,000 lines of code. Unit tests account for 30-40% of that total and execute in under 10 seconds. The repository tests use an in-memory SQLite database.

Design Patterns

• Design Patterns used in this project.

Architecture

• Action

  • Command and Queries are the Use Cases and main entry-point into the application.

  • Command Actions are dispatched to the CommandBusInterface to be handled.

    • There is no return value from the $this->dispatch(...) method. Only exceptions are thrown if the Command is invalid.

  • Query Actions are dispatched to the QueryBusInterface to be handled. Instead of returning the Product entity, the handler will inject a ProductDTOBuilder object into the Response. The DTO Builder is used to produce a ProductDTO which can be retrieved using the $response->getProductDTO() method.

    HTML Template:

  • Both implementations (QueryBus) defer to the MapperInterface to determine the location of the class to handle the execution.

  • This CQRS strategy allows us to separate Commands from Queries while also keeping the Entity business objects separate from the main application. We prefer not to expose internal classes containing methods with business logic. This also serves to decouple the main application from the Use Cases handler implementation. The main application only needs to know about the Use Case Actions.

• Domain Event

  • Domain Events can be raised in the Entity layer and are dispatched in the service layer.

  • Events can be dispatched directly in the service layer. (deprecated)

• Service

  • These are the domain services to manage persisting domain state to the database through repositories. They contain behavior related to multiple Entities and any business logic that does not fit any specific Entity or single Use Case.

• Entity

  • These are plain old PHP objects. You will not find any ORM code or external dependencies here. This is where the relationships between objects are constructed. An Entity contains business logic and behavior with high cohesion to its own properties. Business logic related to the data of a single instance of an Entity belongs here.

• EntityRepository

  • This module is responsible for storing and retrieving entities. Doctrine 2 is used in this layer to hydrate Entities using the Data Mapper Pattern.

• EntityDTO

  • These classes are simple anemic objects with no business logic. Data is accessible via public class member variables. Using the EntityDTOBuilder, the complete network graph relationships are available (e.g., withAllData()) prior to calling build(). The primary reason for using these Data Transfer Objects (DTO) is to flatten the object graph from lazy loaded Doctrine proxy objects on the Entities for use in view templates. This avoids lazy loaded queries from being executed outside the core application and somewhere they don't belong, such as in a view template.
• Lib
  • This is where you will find a variety of utility code including the Payment Gateway (src/Lib/PaymentGateway).

Installation

Add the following lines to your composer.json file.

Unit Tests:

    vendor/bin/phpunit

With Code Coverage:

    vendor/bin/phpunit --coverage-text --coverage-html coverage_report

Run Coding Standards Test:

    vendor/bin/phpcs -p --standard=PSR2 src/ tests/

Count Lines of Code:

    vendor/bin/phploc src/ tests/ --names="*.php,*.xml"

Export SQL

    vendor/bin/doctrine orm:schema-tool:create --dump-sql
    vendor/bin/doctrine orm:schema-tool:update --dump-sql

License