#note
[https://www.slideshare.net/kawasima/atomic-architecture-160588212](https://www.slideshare.net/kawasima/atomic-architecture-160588212)
# 前提知識
## Atomic
ref : [Simple Made Easy](https://www.infoq.com/presentations/Simple-Made-Easy/)
- Value : 値や値の集合
- Type : 型
- Inner Represention : 内部表現
- Functions (pure) : 副作用のない関数
- Identity : 値の一意性
- Time : ビジネスロジックにおける時間
- Name Space : 名前空間
## Type as Constraint
ref : [Type driven development](https://www.manning.com/books/type-driven-development-with-idris)
C
```
// VALUE: {TYPE, INNER REPRESENTATION}
int a = 3; // 3: {int, 3}
a = 4;
// if(a.TYPE == 4.TYPE) { a = 4 } else { ERROR("type not correct"); } のように考える
```
Typeを代入時のValueの制約として考えることができる。
ランタイム時にこの制約を解決するのが ### 動的型付け言語
、コンパイルタイムで解決するのが ### 静的型付け言語
# 構造の理解
## Object
- Identity
- State
- Value
- Time
- Class
- Name space
- Field
- Type
- Method
- Function
## DDD
- Value Object
- Value
- Entity
- Event Entity : システム上記録されるべき、コトを表現するEntity
- Identity
- Value
- Time
- Resource Entity : ある状態を持って状態遷移をしていくEntity
- Identity
- State
- Value
- Time
- Domain Service
- Function
# 時間の捉え方
### Time
というのは、状態遷移上でのある時点を表現していて、`a: {int, 3}` はどこかのタイミングでは `a: {int, 6}`になっている可能性がある。### Time
を扱えないようにして、### Value
を変更不可にすればImmutableになるが、Immutableだけでは変更コストが高くなってしまうことがあるのでバランスが重要になる。
# Epochal Time Model
State
- Value
という構造で ### Time
を変更できないImmutableな形にした上で ### Function
でStateを扱うようにする。
bash
```
State(t1) --Function(pure)--> State(t2) --Function(pure)--> State(t3)
```
関数型の考え方はこれ
# Ref
[/kawasima/アーキテクチャ大全](https://scrapbox.io/kawasima/アーキテクチャ大全) [https://www.slideshare.net/kawasima/atomic-architecture-160588212](https://www.slideshare.net/kawasima/atomic-architecture-160588212)