Sample project that demonstrates how simple e-shop cart can look like. Created to show how do I understand domain-driven design.
- Domain objects
- 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
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.
How to Assemble Real Application
We have to implement domain interfaces by our infrastructure, eg. if we use Doctrine, we implement
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
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.
This project was written in the spirit of TDD, see commits.