#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)