캘리더 설계하기 - 어렵다

반복일정을 어떻게 설계할 것인가가 참으로 문제이다.

일단 다음을 참고하자. 물론 여기에도 당신이 원하는 답은 없을지 모른다.

Calendar Domain with Repeating Events
http://tech.groups.yahoo.com/group/domaindrivendesign/message/16930

Martin Fowler
http://www.martinfowler.com/apsupp/recurring.pdf

멜링리스트로부터 시작된 여행

어제 야후그룹의 멜링리스트 2개를 가입했는데 오늘 아침에 온 메일 갯수가 100개가 넘는다.
extremeprogramming, domaindrivendesign.

흠... 메일 읽는데에도 엄청난 시간이 소모되겠는걸?

XP에서는 주로 TDD 얘기를 하는거 같고...
몇 개를 간간히 훝어 보다가 하나를 읽게 되었는데 CQRS라는 얘기가 나온다.

첨 듣는 용어인데?
Domain Driven Design책에 나오는건가?

Command / Query Resposibility Separation 이란다. 더 검색을 해보니

http://jonathan-oliver.blogspot.com/2009/10/dddd-why-i-love-cqrs.html
http://jonathan-oliver.blogspot.com/2009/03/dddd-and-cqs-getting-started.html

이런게 걸렸다. 흠... 좀 더 알아봐야겠는걸...

https://jdon.dev.java.net/

이런 것도 걸렸다. JdonFramework = DDD + Domain Events+ Ioc/DI + AOP + CRUD + Cache.
머 이런거란다... 일단 흥미롭다는 생각.

또 어쩌다 이런 링크도 걸렸다. Temporal DB라는데.. 머에 쓰는 물건인지...
(누군가 공유 캘린더 시스템을 만들다 던진 질문에 이런 것에까지 답변이 이른 모양이다)
http://www.cs.arizona.edu/~rts/publications.html

끝이 없다. 하~

DDD

미루고 있다가 오늘에야 결심하고 읽었네.
* 도메인 객체가 repository를 가지고 있다는 점은...

참조: Eternity's Chit-Chat : 카테고리 > Domain-Driven Design (Google 사이드위키에서 보기)

aggregate 개념

글쿤...

참조:

"따라서 주문, 주문 항목은 하나의 객체 클러스터를 구성하며, 고객, 상품은 주문 클러스터에 속하지 않는 독립적인 객체로 존재한다. 이처럼 변경에 대한 불변식을 유지하기 위해 하나의 단위로 취급되면서 변경의 빈도가 비슷하고, 동시 접근에 대한 잠금의 단위가 되는 객체의 집합을 AGGREGATE라고 한다."
- Eternity's Chit-Chat : Domain-Driven Design의 적용-2.AGGREGATE와 REPOSITORY 1부 (Google 사이드위키에서 보기)