
1. Project Structure - 회사, 팀 등 개발 목적과 규모에 따라서 틀려진다. 때문에 무조건 DDD가 좋다고 할 수 없다. 2. DDD Detail (3-2 기준) 1. Interface - 사용자나 컴퓨터 시스템에게 정보를 보여주고 사용자의 명령을 해석하는 일을 책임진다. 2. Application - 소프트웨어가 수행할 작업을 정의하고 표현력 있는 도메인 객체가 문제를 해결하게 한다. 이 계층에서 책임지는 작업은 업무상 중요하거나 다른 시스템의 응용 계층과 상호작용하는 데 필요한 것들이다. 이 계층은 얇게 유지된다. 여기에는 업무 규칙이나 지식이 포함되지 않으며, 오직 작업을 조정하고 아래에 위치한 계층에 포함된 도메인 객체에게 작업을 위임 한다. 업무 상황을 반영하는 상태가 없지만, ..
Programming/DDD
2019. 8. 3. 21:38
공지사항
최근에 올라온 글
최근에 달린 댓글
- Total
- Today
- Yesterday
링크
TAG
- Sprint RetryTemplate
- scikit-learn
- Join Table
- Discriminate Mapping
- RetryTemplate
- Registrar
- Criteria
- Charles proxy
- SmartLifecycle
- java generic
- @Primary
- DI
- 복합키 Mapping
- Mapping
- JPA
- Embeddable Mapping
- guava
- Property
- Query DSL
- Spring Registrar
- Akka
- Spring JDBC Template
- JPA Criteria
- Embedded Mapping
- Spring
- java Equals
- docker
- Typesafe Config
- spring spel
- java EqualsAndHashCode
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
글 보관함