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...
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.
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.
Take a loot at app.php
We have to implement domain interfaces by our infrastructure, eg. if we use Doctrine, we implement DoctrineRepository,
if we use CSV for storing #, 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.
This project was written in the spirit of TDD, see commits.