- Published on
Buid first bounded context
- Authors
- Name
- sinhnt
- @sinhnt
References
Introduce
Get familiar with Entity and Value Object. Then build a snack machine around these concepts.
DDD Components
DDD and UT
- UT coverage vs value distribution, at some point you might found that the value of reaching higher code coverage does not bring much value compare to the effort you invest to it. This number is around 80%.
- Domain model (A, E, VO, DE): 100% UT coverage
- Repossitory, Application Services, Factories: Not required UT, but IT.
- First, implement your model and refine it. Then apply TDD later (Write test first, then implement your model).
Problem
- Problem Domain/Domain: the actual problem of the software we are going to solve.
- Core Domain is the subset of domain: the most important part of the software.
- Bissiness logic/Bissiness rule/domain logic/domain knowledge, and domain model are synonymous.
Concepts
- Entity vs Value Object: Both are code repensentation of the real world object.
- Types of equality:
- Structure equality: Two objects are equal if they have the same value for all property (VO)
- Identity equality: Two objects are equal if they have the same identity. (E)
| Entity (E) | Value Object |
|---|---|
Have Id property | Don't have Id property |
| Identity equality (Compare Id) | Structure equality (Compare all property) |
| Mutable | Immutable (Should create a new instance when changing the value) |
| Can be treated interchangeably if Structure equality is satisfied | |
| Doesn't have own table in database??? |
How to recognize a Value Object?
- It more depends on the domain you work on, a concept can be an E in one domain and a VO in another domain.
- Use the characteristics of VO and E to decide.
- Prefer VO over E because Value Objects are light-weight, should put most of the logic in VO
- E act as a wrappers
- Don't hestitate to update your domain model, example changing from VO to E if it's more suitable.
Problem domain description
Build a software for a snack machine, which can:
- Insert money
- Return money
- Buy snack
Here is the UI of snack machine app:
Domain model design
SnackMachine Entity
- Money Inside : Money VO
- Money InTransaction : Money VO
Money Value Object
- int OneCentCount
- int TenCentCount
- int OneDolarCount
- int FiveDolarCount
- int TwentyDollarCount
Database Design
- Confirm with domain expert where which state of the system should be persistence.
- VO should not have it own table, include VO property in its Entity table columns.
Our Database design:
- [PK] SnackManchineID
- [int] OneCentCount
- [int] TenCentCount
- [int] OneDolarCount
- [int] FiveDolarCount
- [int] TwentyDollarCount