Skip to content

Latest commit

 

History

History
51 lines (33 loc) · 2.62 KB

readme.md

File metadata and controls

51 lines (33 loc) · 2.62 KB

Cart

Scrutinizer Code Quality Code Coverage Travis CS & Static Analysis Build Status

Sample project that demonstrates how simple e-shop cart can look like. Created to show how do I understand domain-driven design.

  • Domain objects
  • Layers
  • Unit testing
  • Contract testing
  • Doctrine infrastructure

You can also see how do I program, commit, what technology I can handle...

Dynamic Prices

Prices are not stored in the Cart itself but are loaded on demand. This is a common use-case because we usually need fresh prices from a database or ERP.

Cart is separated from "loading prices" by an interface Prices. This is a domain element but have to be implemented by the project needs - by API calls or database queries.

Fixed Prices

Once we add a product into the cart, the price may be fixed. If it is the project use-case, check out fixed-prices version.

How to Assemble Real Application

Demo

Take a loot at app.php

Longer explanation

We have to implement domain interfaces by our infrastructure, eg. if we use Doctrine, we implement DoctrineRepository, if we use CSV for storing pricing, we implement CsvPrices and so on by the project needs.

We can use domain objects directly in UI/CLI/target layer, and then we have to pass objects like Repositories to that layer. Or we can wrap domain objects into classes that represent full use-cases. You may call them handlers/facades/useCases/... depending on the project infrastructure.

Then we register these classes in or favorite DI container. If you don't know how, you can find inspiration that uses Symfony/DI ContainerBuilderFactory.

TDD

This project was written in the spirit of TDD, see commits.