Cart
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
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.
Then we register these classes in or favorite DI container.
If you don't know how, you can find inspiration in DependenciesTest.
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.
TDD
This project was written in the spirit of TDD, see commits.