Whiteship's Note


[DDD] User-Familly 구현

JEDI/DDD : 2009.06.22 18:53


User-Familly 관계부터 생각해보면, User가 일방적으로 여러 Familly를 가지고 있다고 볼 수 있습니다. 다중성(?)은 User에서 Familly쪽으로 1:대 관계입니다. (형제 자매가 같이 입사한 경우 다:다가 될 수도 있지만, 드문 경우니깐 중복 데이터 상관하지 않고 일단은 1대다로 ㄱㄱ, ) 생명주기를 생각해보면, Familly가 User에 종속되어 있습니다. 타입을 생각해보면 User는 엔티티가 거의 확실하고, Familly는 Value 타입에 가까운 듯 합니다. 하지만 편의상 id를 주고 관리하렵니다.

자 그럼 이제 필요한 도메인 클래스를 추가하고 속성들을 만든 다음 관계를 명시합니다.

class User {
...
    @OneToMany(cascade = { CascadeType.ALL })
    Set<Familly> famillies;
...

}

여기서 준 @OneToMany로 다중성이 어떤지 나타나고, Familly의 생명주기가 User에 종속적이라는 것이 드러납니다.

다음은 UserController(UC)로 갑니다. FamillyController를 만들 필요 없이, Familly와 연관되는 부분과 관련하여 그 요청을 UC가 처리하게 합니다. 화면상으로는 User의 수정화면에서 Familly 그리드가 보이고, 거기에 추가하는 버튼과, 수정하는 버튼이 달려있습니다.


새로 개선한 OSAF를 사용하여 만든 컨트롤러에 Familly를 그리드, 추가, 수정을 다룰 핸들러 메서드를 추가했습니다.

@Controller
@RequestMapping("/base/user/*.do")
public class UserController extends GenericController<User, UserService, UserRef, UserValidator, UserParams>{

    public UserController() {
        super(User.class);
    }

    @Autowired FamillyValidator famillyValidator;

    @RequestMapping
    public void famillygrid(@RequestParam int userid, ModelMap model, OrderPage orderPage){
        if (orderPage.getOrder() == null) orderPage.setOrder("name asc");
        model.addAttribute("list", service.findFamilliesBy(userid));
        model.addAttribute("orderPage", orderPage);
    }

    @RequestMapping(value="/base/user/famillyadd.do", method=RequestMethod.GET)
    public void famillyadd(ModelMap model){
        model.addAttribute("model", new Familly());
    }

    @RequestMapping(method=RequestMethod.POST)
    public String famillyadd(int userid, @ModelAttribute("model") Familly familly, BindingResult result,
            SessionStatus status){
        famillyValidator.validate(familly, result);
        if (result.hasErrors())
            return "/base/user/famillyadd";
        else {
            service.addFamilly(userid, familly);
            status.setComplete();
            return CommonPages.CLOSE_GRID_REFRESH;
        }
    }

    @RequestMapping(value="/base/user/famillyupdate.do", method=RequestMethod.GET)
    public void famillyupdate(int famillyid, ModelMap model){
        model.addAttribute("model", service.findFamillyById(famillyid));
    }


}

thin facade 역할을 하고 있는 service를 이용하고 있습니다.

@Service
@Transactional
public interface UserService extends GenericService<User, UserParams>{

    Set<Familly> findFamilliesBy(int userid);

    void addFamilly(int userid, Familly familly);

    Familly findFamillyById(int famillyid);

}

인터페이스에 추가해주고,,, 실제로 하는 일은 대부분이 도메인 또는 dao로 위임하는 것입니다.

@Service
@Transactional
public class UserServiceImpl extends
        GenericServiceImpl<User, UserParams, UserDao> implements
        UserService {

    public Set<Familly> findFamilliesBy(int userid) {
        return get(userid).getFamillies();
    }

    public void addFamilly(int userid, Familly familly) {
        get(userid).addFamully(familly);
    }

    public Familly findFamillyById(int famillyid) {
        return dao.fingFamillyById(famillyid);
    }

}

그럼 도메인에서 할 일은 도메인에서 처리를 하고..

    public Set<Familly> getFamillies() {
        if (famillies == null)
            famillies = new HashSet<Familly>();
        return famillies;
    }

    public void addFamully(Familly familly) {
        getFamillies().add(familly);
    }

DAO에서 할일은 DAO에서 처리합니다,

    public Familly fingFamillyById(int famillyid) {
        return (Familly) getSession().createQuery(
                "from Familly where id = " + famillyid).uniqueResult();
    }

어디서 처리하든 tx facade 역할을 하고 있는 service를 거쳐왔기 때문에, 트랜잭션 처리가 됩니다.

ps: 스프링 @MVC 혹은 OSAF의 버그(?) 발견..

    @RequestMapping(value="/base/user/famillyadd.do", method=RequestMethod.GET)
    public void famillyadd(ModelMap model){
        model.addAttribute("model", new Familly());
    }

여기서 @RequestMapping의 value를 주지 않아도(CoC로 인해 같은 결과가 나와야 함) 똑같이 동작해야 하는데, 생략할 경우, seach.do를 실행할 때(위 메서드와는 전혀 관계 없는 OSAF GenericController의 update() 메서드 시그너쳐 int id를 Integer로 바꾸라는 에러가 발생함.. @_@)


'JEDI > DDD' 카테고리의 다른 글

[DDD] User-Familly 구현  (0) 2009.06.22
[DDD] Whiteship's DDD 아키텍처 수정  (6) 2009.06.16
[DDD] Whiteship's DDD 아키텍처  (10) 2009.06.12
[DDD] DDD 입문에 좋은 글  (4) 2009.06.11
파트 3: Refactoring Toward Deeper Insight  (0) 2008.10.24
Factories  (0) 2007.12.25
Aggregates  (0) 2007.12.18
Modules  (2) 2007.12.14
Services  (2) 2007.12.13
DAO vs Repository  (4) 2007.12.04
DTO(Data Transfer Object)  (2) 2007.11.21
top

TAG 1대다, DDD, OSAF

[DDD] Whiteship's DDD 아키텍처 수정

JEDI/DDD : 2009.06.16 18:17



Repository 역할이 DAO로 단순 위임 밖에 없어서, Repository를 없애고 그 자리에 DAO를 뒀습니다. Entity에서 이 객체를 사용하여 필요한 작업들을 할 겁니다. 이전의 Facade 역시 이름을 Service로 바꾸고, Transaction을 책임지게 했습니다. 이 서비스는 별다른 역할 없이 Domain 객체나 Dao로 역할을 위임하는 Thin Service입니다.

구조는 기존의 계층형 구조(Controller -> Service -> Dao)와 거의 비슷해 보이지만, 일단 Entity에서 Dao를 들고 예전에 서비스 계층에서 처리했던 비즈니스 로직을 담당하게 되었다는 것, 그 결과 Service의 일은 도메인 객체로의 단순 위임으로 바뀌었다는 점이 주요 특징으로 볼 수 있겠습니다. 또한, 모든 domain 클래스에 대한 C, S, D를 만들던 것과 달리 Entry Point에 해당하는 Entity에 대해 C, S, D를 제공하는 구조입니다. 즉 그림에서 Address라는 Value 타입과 OrderLine이라는 레퍼런스 타입에 대한 C, S, D는 볼 수 없죠.

'JEDI > DDD' 카테고리의 다른 글

[DDD] User-Familly 구현  (0) 2009.06.22
[DDD] Whiteship's DDD 아키텍처 수정  (6) 2009.06.16
[DDD] Whiteship's DDD 아키텍처  (10) 2009.06.12
[DDD] DDD 입문에 좋은 글  (4) 2009.06.11
파트 3: Refactoring Toward Deeper Insight  (0) 2008.10.24
Factories  (0) 2007.12.25
Aggregates  (0) 2007.12.18
Modules  (2) 2007.12.14
Services  (2) 2007.12.13
DAO vs Repository  (4) 2007.12.04
DTO(Data Transfer Object)  (2) 2007.11.21
top


[DDD] Whiteship's DDD 아키텍처

JEDI/DDD : 2009.06.12 11:23


기대는 하지 마시구요. @_@ 기존 틀(빈약한 도메인 객체 + 두꺼운 서비스 계층)에서 벗어난다는게 이렇게 머리 아픈 일인지 몰랐습니다. DDD 공부라도 제대로 했었어야 하는데.. 역시 개념없는 코드와 코드 없는 개념은 아무것도 아닌 것 같아요. 힘 없는 정의와 정의없는 힘처럼... 각설하고.. 오늘 구현해볼 아키텍처를 그려봤습니다.



일단 Web 계층에서는 Application 계층에 있는 Thin Facade 내지 서비스를 호출할 겁니다.

Thin Facade는 도메인 객체로 대부분의 역할을 위임할 겁니다.

도메인 계층에서는 Thin Facade로 부터 어떤 일을 위임 받은 도메인 객체는 비즈니스 로직을 담당할 것이고
- 컬렉션에 저장, 조회 등의 작업을 할 때는 계층에 위치한 Repository를 이용할 겁니다. 여기서 Repository는 DAO와는 개념이 다르다(참조: http://aeternum.egloos.com/1160846)는 것에 주의해 주세요.
- Repository는 모든 Entity가 아닌, Entry Point에 해당하는 Entity에 대한 것만 만들 겁니다.
- Email, JMS 등의 기능이 필요하다면 Infrastructure에서 제공하는 서비스를 이용할 겁니다.

시나리오 1: User


UserController가 요청을 받으면 UserFacade가 이 요청을 받아서 User의 특정 메서드를 호출하고, User는 UserRepository를 사용하여 원하는 작업을 한다.

시나리오 2: User->Address


위 상황에서 Value 타입인 Address가 추가 됐을 때 모습으로 별반 달라진 건 없음. Value 타입이 Entity 타입과 어떤 차이가 있는지 보여주는 시나리오.

시나리오 3: User->Address, Order


Order라는 새로운 Entity이자 Entry Type이 추가되자 Controller, Facde, Repository, Dao가 추가된다. User와 Order는 양방향 관계로 서로가 서로를 참조한다. 비즈니스 요구사항에 따라 방향성은 달라질 수 있다. 또한 현재는 각자가 자신의 Repository만 참조하고 있는데, 이 모습도 비즈니스 요구사항에 따라 달라질 수 있다. 중요한 건, 비즈니스 요구사항에 따라 도메인 객체만 변경하면 될 뿐, 나머진 그대로라는 것이다.

주의 할 것은 전체 아키텍처에서도 그렸듯이 도메인 계층에서 Application 계층을 참조하지 않는다는 것이다. Application 계층을 참조할 일이 있다는 것은 도메인 계층이 다시 Application 계층으로 일을 넘긴다는 것인데, 그렇게 되면 Thin Facade라는 가정이 어긋나게 되고 비즈니스 로직이 Application 계층쪽으로 새어나가게 될 것이다.

시나리오 4: User->Address, Order->OrderLine


이번에는 새로운 Entity OrderLine을 추가했다. 하지만 이 Entity는 Entry Point가 아니라 Order에 종속된 생명주기를 지나고 있다. 따라서 Order가 OrderLine까지 같이 관리하며 OrdeLineRepository는 만들지 않는다. 대신 Infrastructure에 OrderLineDao를 추가하여 OderRepository가 OrderLine을 DB에 넣을 때 이용할 수 있게 도와준다.

이제 구현해보는 일만 남았군요. 캬~~ 코딩하기 전에 그림 그려보는 것도 좀 도움이 되네요. 코딩하면서 계속 디자인을 바꾸니깐.. 테스트고 뭐고.. @_@ 일단 저렇게 큰그림 잡고 조금씩 테스트 해 가면서 기왕이면 TDD로 ㄱㄱ 해보렵니다! 파이팅!! 오늘은 이거 못 만들면 퇴근 못하니깐...ㄷㄷㄷㄷㄷ... 내일 스터디는 밤새고 가야할지도...??? 헤헷 후딱 하고 퇴근해버려야지~

'JEDI > DDD' 카테고리의 다른 글

[DDD] User-Familly 구현  (0) 2009.06.22
[DDD] Whiteship's DDD 아키텍처 수정  (6) 2009.06.16
[DDD] Whiteship's DDD 아키텍처  (10) 2009.06.12
[DDD] DDD 입문에 좋은 글  (4) 2009.06.11
파트 3: Refactoring Toward Deeper Insight  (0) 2008.10.24
Factories  (0) 2007.12.25
Aggregates  (0) 2007.12.18
Modules  (2) 2007.12.14
Services  (2) 2007.12.13
DAO vs Repository  (4) 2007.12.04
DTO(Data Transfer Object)  (2) 2007.11.21
top


[DDD] DDD 입문에 좋은 글

JEDI/DDD : 2009.06.11 12:45


여기에 왕창있더군요. 사부님이 읽고 공부하라고 적극 추천해주는 바람에 출근해서 지금까지 모두 정독해버렸습니다. 개념 설명도 충분하고 중간 중간 코드도 같이 주셔서 이해하기가 더 좋았습니다. TDD까지 권하시는 센스.. 캬~~ 읽으면서 많이 감탄했네요.

이터니티님 감사합니다. 잘 읽었습니다~ 계속해서 연재해 주세요~

2009/03/25   Domain-Driven Design의 적용-4.ORM과 투명한 영속성 4부 [1]
2009/02/27   Domain-Driven Design의 적용-4.ORM과 투명한 영속성 3부
2009/02/23   Domain-Driven Design의 적용-4.ORM과 투명한 영속성 2부
2009/02/15   Domain-Driven Design의 적용-4.ORM과 투명한 영속성 1부
2009/01/18   Domain-Driven Design의 적용-3.Dependency Injection과 Aspect-Oriented Programming 7부 [2]
2009/01/02   Domain-Driven Design의 적용-3.Dependency Injection과 Aspect-Oriented Programming 6부
2008/12/24   Domain-Driven Design의 적용-3.Dependency Injection과 Aspect-Oriented Programming 5부 [2]
2008/12/17   Domain-Driven Design의 적용-3.Dependency Injection과 Aspect-Oriented Programming 4부
2008/12/13   Domain-Driven Design의 적용-3.Dependency Injection과 Aspect-Oriented Programming 3부
2008/12/09   Domain-Driven Design의 적용-3.Dependency Injection과 Aspect-Oriented Programming 2부
2008/12/05   Domain-Driven Design의 적용-3.Dependency Injection과 Aspect-Oriented Programming 1부
2008/11/30   Domain-Driven Design의 적용-2.AGGREGATE와 REPOSITORY 5부
2008/11/27   Domain-Driven Design의 적용-2.AGGREGATE와 REPOSITORY 4부
2008/11/25   Domain-Driven Design의 적용-2.AGGREGATE와 REPOSITORY 3부
2008/11/23   Domain-Driven Design의 적용-2.AGGREGATE와 REPOSITORY 2부
2008/11/20   Domain-Driven Design의 적용-2.AGGREGATE와 REPOSITORY 1부
2008/11/17   Domain-Driven Design의 적용-1.VALUE OBJECT와 REFERENCE OBJECT 4부
2008/11/17   Domain-Driven Design의 적용-1.VALUE OBJECT와 REFERENCE OBJECT 3부
2008/11/16   Domain-Driven Design의 적용-1.VALUE OBJECT와 REFERENCE OBJECT 2부
2008/11/15   Domain-Driven Design의 적용-1.VALUE OBJECT와 REFERENCE OBJECT 1부 [2]


'JEDI > DDD' 카테고리의 다른 글

[DDD] User-Familly 구현  (0) 2009.06.22
[DDD] Whiteship's DDD 아키텍처 수정  (6) 2009.06.16
[DDD] Whiteship's DDD 아키텍처  (10) 2009.06.12
[DDD] DDD 입문에 좋은 글  (4) 2009.06.11
파트 3: Refactoring Toward Deeper Insight  (0) 2008.10.24
Factories  (0) 2007.12.25
Aggregates  (0) 2007.12.18
Modules  (2) 2007.12.14
Services  (2) 2007.12.13
DAO vs Repository  (4) 2007.12.04
DTO(Data Transfer Object)  (2) 2007.11.21
top

TAG DDD

파트 3: Refactoring Toward Deeper Insight

JEDI/DDD : 2008.10.24 13:05


리팩터링 수준

다른 책들은 너무 로우 레벨로 얘기하는데 그 보다는 도메인에 대한 통찰을 통한 또는 모델이 말하고자 하는 바를 분명하게 하는 것이 시스템의 실용성에 더 지대한 영향을 주는 리팩터링 이라는 이야기..
The refactorings that have the greatest impact on the viability of the system are those motivated by new insights into the domain or those that clarify the model's expression through the code.
Deep Model

모델을 좀 더 심도있게 바라보도록.. 피상적인 모습으로만 축출한 모델이 다가 아니라는거...
A deep model provides a lucid expression of the primary concerns of the domain experts and their most relevant knowledge while it sloughs off the superficial aspects of the domain.
Supple Design

변경을 반영할 수 있는 설계가 되어야 한다.

In a process of constant refactoring, the design itself needs to support change.
Deep Model과 Supple Design은 Model-Driven Design을 뒷받침하는 두 개의 축이다.
A MODEL-DRIVEN DESIGN stands on two legs. A deep model makes possible an expressive design. At the same time, a design can actually feed insight into the model discovery process when it has the flexibility to let a developer experiment and the clarity to show a developer what is happening.
The Discovery Process

좋은 모델을 찾아가는 과정은 개인의 창의성에 달려있기도 하지만, 여러 패턴을 따를 수도 있겠다.
You will usually depend on creativity and trial and error to find good ways to model the concepts you discover, but sometimes someone has laid down a pattern you can follow.

가끔은 이론적인 얘기로 머리를 환기시키는 것도 좋네요.

'JEDI > DDD' 카테고리의 다른 글

[DDD] User-Familly 구현  (0) 2009.06.22
[DDD] Whiteship's DDD 아키텍처 수정  (6) 2009.06.16
[DDD] Whiteship's DDD 아키텍처  (10) 2009.06.12
[DDD] DDD 입문에 좋은 글  (4) 2009.06.11
파트 3: Refactoring Toward Deeper Insight  (0) 2008.10.24
Factories  (0) 2007.12.25
Aggregates  (0) 2007.12.18
Modules  (2) 2007.12.14
Services  (2) 2007.12.13
DAO vs Repository  (4) 2007.12.04
DTO(Data Transfer Object)  (2) 2007.11.21
top


Factories

JEDI/DDD : 2007.12.25 00:12


Entity와 Aggregate는 보통 생성자에서 만들기는 너무 복잡해질 정도로 커지는 경향이 있다.

보통 객체를 요구하는 쪽에서 여러 인자들과 함께 생성자를 호출한다. 이러면 객체를 생성할 때 너무 많은 정보들을 알게 된다. 즉, 객체에 대한 클라이언트들이 객체 생성에 관한 정보를 알게 되는 것이고, 이 것은 도메인 객체와 Aggregate에 대한 Encapsulation을 깨트린다.

실제에서도 플라스틱, 고무, 철, 실리콘 등으로 프린터를 직접 만들진 않는다. 이런 복잡한 것들을 포함시키면 이해하기 어려운 설계가 된다. 따라서 복잡한 객체 생성 과정을 캡슐화하는 새로운 개념이 필요하다. 그게 바로 Factory다.

객체 생성 과정을 원자화Atomic하는 것은 중요하다. 그렇지 않으면, 만들다 만 객체를 생성할 수도 있다. 특히 Aggregate의 경우에 그렇다. 객체 생성이 실패하면, 예외를 발생시켜서 잘못된 값이 전달되지 않도록 해야한다.

따라서 복잡한 객체나 Aggregate 객체를 생성하는 책임을 별도의 객체로 위임하는 것이 좋다. 인터페이스를 제공하여 클라이언트가 구현 클래스에 직접 접근할 필요가 없도록 하라.

Factory와 관련된 GoF의 Design Pattern 중에 Factory Method 패턴과 Abstract Factory 패턴이 있다. 디자인 관점이 아니라 도메인 모델링 관점에서 살펴보겠다.

사용자 삽입 이미지
참조 : http://en.wikipedia.org/wiki/Factory_method_pattern

Factory Method는 다른 객체를 생성하는데 필요로 하는 정보를 가지고 숨겨둔 객체 메소드이다. 이것은 클라이언트가 Aggregate에 속한 객체를 얻고 싶을 때 유용하다. Aggregate 루트에 객체 생성을 책임지는 메소드를 추가하면 된다.

사용자 삽입 이미지
참조 : http://www.dofactory.com/Patterns/PatternAbstract.aspx

Abstract Factory는 객체 생성이 더 복잡하거나 객체 생성이 여러 개의 객체 생성을 포함하고 있는 경우에 사용한다. 예를 들어, Aggregate를 생성할 때, 그에 대한 책임을 별도의 Factory 객체에게 위임할 수 있다. Factory를 만드는 것은 객체 캡슐화를 위배하기 때문에 주의깊게 사용해야 한다.

Entity Factory와 Value Object Factory의 차이점. Value Object는 변하지 않는immutable 객체기 때문에, 한 번 만들어 지면 변하지 않아야 한다. Entity 는 immutable하지 않다. 매번 변하며, 식별성identity을 가지고 있다.

다음의 경우 Factory보다는 생성자를 사용하는게 좋다.
  • 객체 생성이 복잡하지 않을 때.
  • 객체 생성이 다른 객체 생성 과정을 포함하고 있지않으며, 오로지 인자로 넘어온 값들만 필요로 할 때.
  • 클라이언트가 구현 과정에 관심이 있을 때.
  • 계층구조가 없는 단순한 타입일 때. 어떤 구현체를 제공해야 할지 선택할 필요가 없기 때문에..
Entity 객체를 가져올 때 주의해야 할 것은 DB의 identity와 객체의 identity를 맞춰주어야 한다는 것이다.

'JEDI > DDD' 카테고리의 다른 글

[DDD] User-Familly 구현  (0) 2009.06.22
[DDD] Whiteship's DDD 아키텍처 수정  (6) 2009.06.16
[DDD] Whiteship's DDD 아키텍처  (10) 2009.06.12
[DDD] DDD 입문에 좋은 글  (4) 2009.06.11
파트 3: Refactoring Toward Deeper Insight  (0) 2008.10.24
Factories  (0) 2007.12.25
Aggregates  (0) 2007.12.18
Modules  (2) 2007.12.14
Services  (2) 2007.12.13
DAO vs Repository  (4) 2007.12.04
DTO(Data Transfer Object)  (2) 2007.11.21
top

TAG DDD, FACTORY

Aggregates

JEDI/DDD : 2007.12.18 14:33


Aggregate는 객체의 소속Ownership과 경계Boundary를 정의하기 위해 사용하는 도메인 패턴이다.

모델은 많은 도메인 객체들을 포함하고 있을 것이며, 이 도메인 객체들은 서로 거미줄처럼 연결되어 있을 것이다. 실제 도메인에서의 연관 관계는 코드와 DB에도 그대로 반영되어야 한다. 마치 한 사람의 고객이 계좌 하나를 가지고 있을 때 Customer와 Account 테이블처럼 말이다.

모델이 복잡해지는 것을 막기 위해서 최대한 간단하고 이해 가능한 수준으로 작성하려 할 것이다. 그러기 위해서 많은 시간을 모델들 사이의 관계를 제거하거나 단순화 하는데 소비한다. 하지만 1:1, 1:다, 다:다 등의 관계를 단순화하는 작업이 그리 간단하지 않은 것 같다.

Invariant도 마찬가지로 신경써야한다. Invariant는 데이터가 변경되더라도 유지되어야 할 규칙을 이야기한다. 하지만 복잡한 관계에서 변경은 도메인 객체에 해를 끼칠 수도 있다. 그래서 신중한 롹킹으로 여러 사용자들이 데이터를 동시에 사용할 수 있도록 한다.

그래서 Aggregate가 필요하다.

사용자 삽입 이미지

Aggregate는 데이터 변경에 영향을 받는 객체들을 하나의 유닛으로 묶어놓은 그룹이다. Root에 해당하는 Entity 객체를 통해서 외부와 내부의 객체들 사이를 경계짓고 있다. 경계 내부에 또 다른 Entity가 있을 때 해당 Entity의 identity는 aggregate 내부에서만 통용되는 지역적인 identity이다.

이렇게 되어있을 때 무경성을 지키는것이 훨씬 편하다. 외부에서 내부에 있는 객체들에 바로 접근할 수 없으며, 최상위 Entity 객체를 통해서 조작되기 때문이다.

또한 내부의 객체에 대한 복사본을 외부로 전달하는 것이 가능하다. 이렇게 되면, 외부에서 해당 객체를 지지고 볶아서 구워 삶아 먹든 별 문제가 없을 것이다.

내부의 객체들은 외부에 있는 다른 Aggregate의 Entity를 참조할 수 있다.
최상위 Entity는 Gloval Identity를 가지고 있다.

'JEDI > DDD' 카테고리의 다른 글

[DDD] Whiteship's DDD 아키텍처 수정  (6) 2009.06.16
[DDD] Whiteship's DDD 아키텍처  (10) 2009.06.12
[DDD] DDD 입문에 좋은 글  (4) 2009.06.11
파트 3: Refactoring Toward Deeper Insight  (0) 2008.10.24
Factories  (0) 2007.12.25
Aggregates  (0) 2007.12.18
Modules  (2) 2007.12.14
Services  (2) 2007.12.13
DAO vs Repository  (4) 2007.12.04
DTO(Data Transfer Object)  (2) 2007.11.21
DDD: putting the model to work  (4) 2007.11.20
top

TAG Agrregate, DDD

Modules

JEDI/DDD : 2007.12.14 23:43


크고 복잡한 애플리케이션에서 모델은 갈수록 커지는 경향이 있다. 그러다가어느 시점에 도달하면 더이상 전체를 파악하기도 힘들고 그들의 관계를 이해할 수도 없을 만큼 복잡해진다.

모듈은 관련된 개념과 작업들을 묶어서 복잡도Complexity를 줄이기 위해 사용한다.

모듈을 사용하는 또 다른 이유는 코드의 품질과 관련이 있다. 높은 응집도Cohesion와 낮은 결합도Coupling을 유지하는 코드가 좋은 코드다.  모듈을 사용하면 응집도를 높이고 결함도를 떨어트린다. 왜냐면 모듈화 함으로써 기능적으로나 논리적으로 관련된 녀석들을 묶어주기 때문에 응집도는 높아지며, 모듈들은 모두 잘 정의된 인터페이스를 가지고 있기 떄문에 결함도를 낮춰준다.

사용자 삽입 이미지

모듈 이름은 유비쿼터스 언어의 일부에서 발췌해야 한다.

모듈을 한 번 만들고 그 역할을 정해두면, 그 내부에 많은 변화가 생기더라도 보통 모듈을 자주 변경하지 않는다. 하지만 프로젝트를 진행하면서 모듈을 얼려두지 말고 진화시키는 것을 권장한다. 모듈을 리팩토링하는 비용이 엄청나다는 것을 알지만 그래도 모듈을 유지하기 위해 돌아가는 방법을 선택하는 것 보다는 모듈을 변경하는게 좋다.

'JEDI > DDD' 카테고리의 다른 글

[DDD] Whiteship's DDD 아키텍처  (10) 2009.06.12
[DDD] DDD 입문에 좋은 글  (4) 2009.06.11
파트 3: Refactoring Toward Deeper Insight  (0) 2008.10.24
Factories  (0) 2007.12.25
Aggregates  (0) 2007.12.18
Modules  (2) 2007.12.14
Services  (2) 2007.12.13
DAO vs Repository  (4) 2007.12.04
DTO(Data Transfer Object)  (2) 2007.11.21
DDD: putting the model to work  (4) 2007.11.20
Building Domain Knowledge  (0) 2007.01.03
top

TAG Modules

Services

JEDI/DDD : 2007.12.13 22:09


DDD Quickly 읽다가 정리합니다.

유비쿼터스 언어를 조사하다 보면 명사는 객체로 동사는 객체의 메소드로 연관시키는 경우가 많다. 그러나 그 중 몇몇은 특정 도메인 객체 어디에도 속하지 않는듯한 동사가 있다. 이러한 것들을 서비스로 등록하라.

예를들어, 예금이체 같은 동사는 Account 라는 두 개의 객체 중 보내는 객체 쪽에 둬야 할까 받는 쪽에 둬야 할까?

서비스는 절대로 도메인 객체에 지녀야 할 행위를 가지고 있어서는 안 된다.

1. 서비스에 의해 수행되는 작업은 Entity나 Value Object에 속하지 않는 도메인 컨셉이다.
2. 수행되는 작업은 도메인에 있는 다른 객체를 참조한다.
3. 작업은 상태 정보를 유지하지 않는다. Stateless

서비스를 사용하면서도 도메인 계층을 독립시키는 것이 중요하다.

사용자 삽입 이미지

서비스는 위 그림처럼 별도의 계층으로 존재하는 것이 아니라, 도메인 객체들과 연관된 서비스라면 도메인 계층에 두고, 애플리케이션 계층과 관련이 있다면 애플리케이션 계층에 둔다고 합니다. 그래서 서비스를 대체 어디에 두어야 할지 결정하는 일이 좀 어렵다고 나와있네요.

예금이체 같은 경우는 도메인 계층에 둘 것이고, 도메인과 관련되어 있진 않지만 애플리케이션에 꼭 필요한 역할...트랜잭션이나 로깅 같은 것들은 애플리케이션 계층에 두면 되겠군요. 이런 것들은 근데 Aspect로 처리하면 될 것 같고 흠.. 폼에 입력된 데이터를 검증할 Validator 같은 녀석들은 어떨까요. 이런것도 애플리케이션 계층에 속하겠죠?

내일은 Module...

'JEDI > DDD' 카테고리의 다른 글

[DDD] DDD 입문에 좋은 글  (4) 2009.06.11
파트 3: Refactoring Toward Deeper Insight  (0) 2008.10.24
Factories  (0) 2007.12.25
Aggregates  (0) 2007.12.18
Modules  (2) 2007.12.14
Services  (2) 2007.12.13
DAO vs Repository  (4) 2007.12.04
DTO(Data Transfer Object)  (2) 2007.11.21
DDD: putting the model to work  (4) 2007.11.20
Building Domain Knowledge  (0) 2007.01.03
What Is Domain-Driven Design  (2) 2007.01.02
top


DAO vs Repository

JEDI/DDD : 2007.12.04 23:21


http://aeternum.egloos.com/1160846 이 글을 참조하세요. 아래 내용은 권해드리지 않는 내용입니다.

나도 DDD 하고싶어 모델링 적용기
Repository Pattern vs. Transparent Persistence

위 두 개의 글의 공통점은 DAO와 Repository의 차이에 대한 고민입니다. 저도 잘 모릅니다. 저는 사실 찬욱군이 쓴 글에 있는 링크를 따라가보지도 않았으며, 얇은 DDD책(DDD Quickly)도 다 읽지 못 했고, 그나마 읽었던 부분들도 잊혀져가고 있습니다.(다시 읽으려고 마음먹었습니다.)

그래도.. 나름대로 생각해 봤습니다. 어차피 작명의 문제이고 누군가 어떤 의도를 가지고 작명을 했을테니 그 뜻은 분명 단어 속에 숨어있겠죠.

DAO는 Data Access Object의 약자로 데이터(베이스)에 접근하는 객체를 나타냅니다. DB 접근하는 일을 분리해 냈습니다. SRP 객체지향 원칙의 사례로 등장했었던 적이 있었는데 어떤 글인지는 모르겠습니다.

Repository는 저장소입니다. 어떤 객체들을 저장하는 장소를 뜻할 것이며, 아마도 DB 자체를 또는 Table 자체 또는 '영속성이 보장되는 저장소'를 객체화한 표현이 아닐까 생각해봅니다. 이것이 필요한 객체는 바로 도메인 객체겠죠.

이정도 정보를 가지고 이 둘의 차이를 살펴보기엔 정말 막연합니다. 그래서 Finder라는 녀석까지 같이 보겠습니다. Finder는 findByXXX 류의 메소드들을 가진 클레스로 이 녀석 역시 DB나 영속성을 보장하는 어떠한 저장소에 접근을 합니다.

기존의 DAO에는 Finder가 하는 일까지 같이 포함하고 있었습니다. 그리고 DDD를 구현한(건지.. 구현 하도록 돕는 건지.. Anyway) ROO 라는 프레임워크에서는 Repository와 Finder로 분리해 두었습니다. 조금 더 세밀하게 SRP를 적용했다고 볼 수 있습니다.

따라서 저는 이렇게 결론을 냈습니다.

사용자 삽입 이미지

그럼 DAO와 Finder를 동시에 두면 어떻게 되는걸까? 라는 생각을 해볼 수 있는데요. DAO는 위에서도 언급했다시피, 데이터에 접근하는 객체입니다. Finder는 무언가를 찾아주는 녀석이죠. 그럼 무언가를 찾아주는 녀석이 매번 데이터에 접근해서 찾아야 하는데 결국 Finder도 DAO라고 볼 수 있지 않을까요? 그럴 때는 가능하다면, 기존의 DAO 이름을 Repository로 변경하는 것이... 좋을 것 같다는 생각을 해봅니다.

'JEDI > DDD' 카테고리의 다른 글

[DDD] DDD 입문에 좋은 글  (4) 2009.06.11
파트 3: Refactoring Toward Deeper Insight  (0) 2008.10.24
Factories  (0) 2007.12.25
Aggregates  (0) 2007.12.18
Modules  (2) 2007.12.14
Services  (2) 2007.12.13
DAO vs Repository  (4) 2007.12.04
DTO(Data Transfer Object)  (2) 2007.11.21
DDD: putting the model to work  (4) 2007.11.20
Building Domain Knowledge  (0) 2007.01.03
What Is Domain-Driven Design  (2) 2007.01.02
top


DTO(Data Transfer Object)

JEDI/DDD : 2007.11.21 12:30


참조 :
http://martinfowler.com/eaaCatalog/dataTransferObject.html
http://en.wikipedia.org/wiki/Data_Transfer_Object
http://www.theserverside.com/discussions/thread.tss?thread_id=32389

찬욱군이 요즘 DTO Assembler를 만들고 있는 것 같습니다. 저는 DTO 개념이 없기 때문에, 오히려 더 복잡해 보이는데 왜 저렇게 해야 되는거지 궁금해 했습니다. 대체 DTO가 뭐길래...그래서 찾아봤습니다.

사용자 삽입 이미지
위 그림은 첫 번째 링크 마틴 파울러 eaa 카탈로그에서 가져왔습니다. 원격 호출을 할 때 호출의 수를 줄이려면, 한 번에 여러 객체를 가져와야 하는데, 메소드가 오직 하나의 객체만 반환할 수 있는 자바같은 언어들은 그런 것이 불가능하기 때문에 고안한 것이 DTO 입니다.

즉, 필요한 정보만 모아놓은 객체가 되겠죠. 따라서 서버 측에서는 이런 객체(DTO)를 지원하기 위해 여러 객체의 정보를 가지고 DTO를 만들어주는 Assembler라는 녀석을 제공해야 하고, 지금 찬욱군이 이 녀석을 만들고 있는 것 같습니다.

두 번째 링크인 위키피디아의 정의를 보면, DAO, 비즈니스 도메인 객체(DO), 그리고 DTO의 차이를 매우 간략하게 말해주고 있습니다.

The difference between Data Transfer Objects and Business Objects or Data Access Objects is that DTOs do not have any behaviour except for storage and retrieval of its own data (accessors and mutators).

무언가 혼란스러움이 생기기 시작합니다. 이제까지 도메인 객체(DO)라고 구현했던 녀석들과 DTO와의 차이가 없습니다. 그 녀석들(DO)도 단순하게 프로퍼티와 세터 게터만 가지고 있었으니까요. 그럼 DTO와 별단 차이가 없기 때문이죠. 이것참... 어쩐지 도메인 객체가 너무 횡하다 했습니다.

MemberDao.save(Member) 같은 메소드는 뭔가 어색하고 Member.join() 하면 그냥 DB 저장이 되야 어색하지 않은데 말이죠. MemberService.getMember(id)를 호출하면, Member 도메인 객체가 아니라, 사용자가 보기 원하는 정보만을 담은 Member DTO를 넘겨주는 것이였군요. 이런식으로 하면 도메인 객체 계층을 눞힐 수 있겠군요.(세워두는 것이 아니라..) 찬욱군이 그린 ROO 아키텍처가 이해가 가기 시작합니다.

저는 저 위의 그림의 Assembler보다 Facade가 더 궁금하네요. 역시 그림도 좋은데 코드가 있어야... 좀 더 명확할텐데 말이죠. DTO와 Assembler 그리고 Facade를 잘 활용한 애플리케이션 코드를 보고 싶네요.

'JEDI > DDD' 카테고리의 다른 글

[DDD] DDD 입문에 좋은 글  (4) 2009.06.11
파트 3: Refactoring Toward Deeper Insight  (0) 2008.10.24
Factories  (0) 2007.12.25
Aggregates  (0) 2007.12.18
Modules  (2) 2007.12.14
Services  (2) 2007.12.13
DAO vs Repository  (4) 2007.12.04
DTO(Data Transfer Object)  (2) 2007.11.21
DDD: putting the model to work  (4) 2007.11.20
Building Domain Knowledge  (0) 2007.01.03
What Is Domain-Driven Design  (2) 2007.01.02
top

TAG DTO

DDD: putting the model to work

JEDI/DDD : 2007.11.20 14:59


59분이라는 비교적 짧은 시간 동안 에릭 에반스가 발표한 자료가 올라왔었네요. Spring 2.5 관련 아티클 보러갔다가 DDD 발표 동영상 발견하고 이거 구경하고 있습니다.

발표자를 중심으로 찍은 화면이 재생되고, PPT는 플래시로 특정 시간마다 한 장씩 자동으로 보여줍니다. 오~ 발표자료 보여주는 데에도 상당히 신경을 쓴 InfoQ 멋집니다.

보러가기

이런.. 마지막에 조금 쉬었다가 2부에서 이어진다고 하는데, 아직 안 올라왔네요.

도메인, 모델, 유비쿼터스 언어, 모델 이름 선택에서 중요한 것, Context Map을 예제를 가지고 설명해줬습니다. 매우 차분하게 말씀하시네요. 목소리 톤이 약간 졸리기도 합니다.

'JEDI > DDD' 카테고리의 다른 글

[DDD] DDD 입문에 좋은 글  (4) 2009.06.11
파트 3: Refactoring Toward Deeper Insight  (0) 2008.10.24
Factories  (0) 2007.12.25
Aggregates  (0) 2007.12.18
Modules  (2) 2007.12.14
Services  (2) 2007.12.13
DAO vs Repository  (4) 2007.12.04
DTO(Data Transfer Object)  (2) 2007.11.21
DDD: putting the model to work  (4) 2007.11.20
Building Domain Knowledge  (0) 2007.01.03
What Is Domain-Driven Design  (2) 2007.01.02
top

TAG DDD

이번 주 나의 시간 측정

JEDI/ToDo : 2007.03.30 23:02



more..


more..


more..


more..


more..


종합 평가
1. 점점 아침에 잠이 많아 지고 있습니다.
2. 수업을 세 번밖에 안 들었군요.
3. 이번주에 제일 많이 한 일 "개발(코딩, 디버깅, 배포)" > "공부(AOP)" > "블로깅"
4. 저녁을 안 먹고 살고 있습니다.
5. 하루라도 블로깅을 안 하면 입안에 가시가 돋을 것 같습니다.

다음 주 계획
1. JSP, Servlet 구동 파악.
2. Spring AOP Reference 6장 공부 & 발표.
3. 운동을 좀 더 자주 하자.

희한하네요. 피로가 쌓였는지 평소 1, 2시에 자는데 벌써 눈이 감기기 시작합니다. 왜이러지;;
anyway good night!
top


이번 주 과제 + 새로운 과제

JEDI/ToDo : 2007.03.30 09:35


1. AJN 서버 - 톰캣 5.5로 재설치, 위키 재설치, 블로그 재설치.
2. Testing 공부 - Agile Java 콜렉션과 I/O,  without EJB 14장, 영회형 블로그.
3. AOP 공부 - Spring AOP 6장, 7장(introduction advice, ProxyFactoryBean).
4. AJAX 공부 - javascript, AJAX 작동 원리.
5. 개발 - classicMania, reportValidator, buyingBook.

이번주 초에 작성한 이번 주 과제에 비하면 상당히 많은 과제들이 주어졌습니다.

다음주 까지 3번을 끝내고 4번을 시작합니다.
1번을 오늘 끝내고 5번 중에 reportValidator를 끝냅니다.
2번중에 Agile Java 책을 내일 끝내고 다음주에 14장을 공부합니다.
5번 중에 buyingBook에 있는 태그 파일에서 EL안에 EL을 사용하지 못하는 문제를 해결해야 합니다. classicMania는 6월까지 니까 다소 널널하네요.

결과적으로 오늘 할 일은 1번, 5번(reportValidator), 3번(introduction, ProxyFactoryBean)
top


ajn 태그 파일 table과 column

JEDI/ToDo : 2007.03.27 17:14


화면에서는 이렇게 사용할 수 있습니다.
    <ajn:table>
        <ajn:column title="순번" property="${order.num}" />
        <ajn:column title="책" property="${order.bookName}" link="${order.link}"/>
        <ajn:column title="신청자" property="${order.owners}" />
    </ajn:table>

table 태그의 내용은 다음과 같습니다.

more..

column 태그의 내용은 다음과 같습니다.

more..


유용하지 않은 이유는..
1. 저 태그를 사용하는 콜렉션의 이름은 무조건 orders 여야 합니다. 아니면 테이블 태그파일에서 리스트의 이름으로 빨간 색 부분을 수정해 주시면 됩니다.
2. 콜렉션에 담겨이는 각각의 객체에 있는 속성들은 꼭 앞에 order를 붙여줘야 합니다.

이렇게 된 이유는..
1. EL 안에 EL이 먹지 않습니다. ${order.${property}} 이런 건 안되더군요.
2. 머리가 나빠서..;; 아마 다른 방법이 있겠죠. displayTag 처럼 잘 돌아가는게 있으니까요.
top


게릴라 서바이버 스터디 :: 이번 주 과제

JEDI/ToDo : 2007.03.25 22:40


요즘 하고 있는 JEDI라는 스터디로.. 제다이가 되기 위해 열심히 수련을 하고 있는 스터디입니다.

1. buying 프로젝트 :: 화면에 버그를 잡아라.
2. 일주일간 행적을 기록하라.(그래야 공부 로드맵을 그릴 수 있을 것이다.)
3. 로드맵을 그려보시게나..
4. 매일 30분 TDD
5. Spring Reference 6, 7장 AOP 정리
6. 다음 매쉬업 만들어야지..기선아..쫌 해!!
7. classic 프로젝트 :: Member 마무리.

월 - 아침 8시 부터 (6, 7)
화 - (5, 1)
수 - (5, 7)
목 - (5, 7)
금 - (5, 7)
토 - (5, 7)
일 - 데이트
매일 할 일 - (2, 4)

top


list.jsp를 태그 파일 사용하여 개선하라.

JEDI/ToDo : 2007.03.23 13:47


일종의 API를 만드는 것으로 사용자가 무척 쉽게 사용할 수 있도록 설계를 해야 합니다.
참조 : 프레임워크의 인터페이스(API)

<ajn:page>
    <ajn:table>
       <ajn:thead>
          <ajn:th title="순번" />
          <ajn:th title="책" />
          <ajn:th title="신청자" />
       <ajn:thead>
       <ajn:tbody>
          <ajn:bookOrderColumn num="1", title="~~", link="~~", owners="~~" />
          <ajn:bookOrderColumn num="1", title="~~", link="~~", owners="~~" />
          <ajn:bookOrderColumn num="1", title="~~", link="~~", owners="~~" />
        </ajn:tbody>
    </ajn:table>
</ajn:page>

태그 파일 사용해서 코드 줄여 보겠다고 만든 원본이 위와 같았습니다. 태그가..page, table, thead, th, tbody, bookOrderColumn 무려 6개.. 기능이 엄청나게 많아서 어쩔 수 없이 복잡한 인터페이스라면 모를까... 기껏 해야 테이블하나 보여줄 뿐인데 말이죠.

<ajn:page title="구매 대행 신청 도서 목록">
    <ajn:table is="list" of="order">
        <ajn:column property="${order.num}" title="순번" />
        <ajn:column property="${order.bookName}" linkProperty="${order.link}" title="책이름"  />
        <ajn:column property="${order.owners}" title="신청자" />
    </ajn:table>
</ajn:page>

지금은 이렇게 바꼈습니다. 태그는 page, table, column 이렇게 세개로 줄었습니다. 대신 태그 파일들의 내부는 이전보다 복잡해 졌지만 그건 태그의 사용자가 고려할 사항이 아니죠.

ps : EL태그 안에 EL태그가 먹힌다면(ex. ${order.${property}})  개선한 코드에서 색칠된 부분을 뺄 수 있습니다.
top


YUI :: DataTable :: 커스텀 태그로 숨기기

JEDI/YUI : 2007.03.20 22:42


<%@ page language="java" contentType="text/html; charset=EUC-KR" pageEncoding="EUC-KR"%>

<%@ taglib prefix="ajn" tagdir="/WEB-INF/tags/ajn"%>

<ajn:page title="구매 대행 신청 도서 목록">

       <ajn:dataTable label="markup">

             <ajn:columnHeader key="index" text="순번" type="number" sortable="true" />

             <ajn:columnHeader key="bookName" text="책이름" type="html" sortable="true" />

             <ajn:columnHeader key="owners" text="신청자 명단" type="html" sortable="false" />

        </ajn:dataTable>

        <ajn:viewTable label="markup" />

        <ajn:table>

             <ajn:bookOrderRow index="1" book="<a href="http://www.amazon.com/exec/obidos/tg/detail/-/1932394230/ref=ord_cart_shr/103-7860518-9786265?%5Fencoding=UTF8&m=ATVPDKIKX0DER&v=glance">JUnit Recipes: Practical Methods for Programmer Testing</a>" members="영회" />

             <ajn:bookOrderRow index="2" book="<a href="http://www.amazon.com/exec/obidos/tg/detail/-/1932394885/ref=ord_cart_shr/103-7860518-9786265?%5Fencoding=UTF8&m=ATVPDKIKX0DER&v=glance">Java Persistence with Hibernate</a>" members="찬욱,기선,한수,계옥,연숙" />

             <ajn:bookOrderRow index="3" book="<a href="http://www.amazon.com/exec/obidos/tg/detail/-/159059584X/ref=ord_cart_shr/103-7860518-9786265?%5Fencoding=UTF8&m=ATVPDKIKX0DER&v=glance">Expert Spring MVC and Web Flow</a>" members="찬욱" />

       </ajn:table>

</ajn:page>

와~ 70줄에 달아던 코드가 불과 15줄로 줄었습니다. 짝짝짝 .. 기선아 귿잡!

문제의 코드들은..<tr> <td>들 뿐만이 아닌 YUI의 자바스크립트.. 그것들을 태그파일로 만들어 버렸더니 코드가 확~ 줄어들었습니다. 예전에 물개 선생님 한테서 안 배웠다면 엄청 고생했을 텐데 말이죠. 새삼 다시 감사합니다. :)

이전에 커스텀 태그를 공부했던 흔적들 입니다.
Custom Tag 만들기
9. Tag만들기

'JEDI > YUI' 카테고리의 다른 글

YUI :: DataTable :: 커스텀 태그로 숨기기  (0) 2007.03.20
HTML 태그를 DataTable로  (0) 2007.03.19
YUI :: DataTable :: DataTable 객체 만들기  (0) 2007.03.18
YUI :: DataTable :: DataSource 객체 만들기  (0) 2007.03.18
YUI :: DataTable :: ColumnSet 객체 만들기  (0) 2007.03.18
YUI :: DataTable :: basic.html  (0) 2007.03.18
숙제  (0) 2007.03.17
Yahoo Wideget 개발 준비  (0) 2007.03.15
YUI(Yahoo! UI Library)  (0) 2007.01.22
top


YUI 코드 간단하게 고치기

JEDI/ToDo : 2007.03.20 16:12


이전 글에 올라온 코드를 보면 상당히 깁니다. 그 코드를 짧게 만드는 방법으로 커스텀태그를 사용해서 스크립트와 table 태그를 처리하기로 했습니다.

1. 링크 문제 해결.
- http://tech.groups.yahoo.com/group/ydn-javascript/message/10728
- http://tech.groups.yahoo.com/group/ydn-javascript/message/10654
- http://tech.groups.yahoo.com/group/ydn-javascript/message/10044 => 이게 대박 글!!

2. 커스텀 태그로 코드 줄수 줄이기.
- YUI :: DataTable :: 커스텀 태그로 숨기기

3. JS 메소드 조사.
- YAHOO.util.Dom.get("markup");
- YAHOO.util.Event.onAvailable("markup", a, a, true);
top


HTML 태그를 DataTable로

JEDI/YUI : 2007.03.19 18:54


ColumnSet의 생성자에 넣어줄 배열을 만들 때 각 Column의 속성 중에 text에 적는 값과 <th> 태그에 적는 값이 같으면 맵핑이 됩니다.

그리고 관련된 css와 js파일을 사용해 주면 IE와 FF에서 동일하게 나타납니다.
FF
사용자 삽입 이미지
IE
사용자 삽입 이미지

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>구매 대행 신청 도서 목록</title>
<link type="text/css" rel="stylesheet" href="../../build/reset/reset.css">
<link type="text/css" rel="stylesheet" href="../../build/fonts/fonts.css">
<link type="text/css" rel="stylesheet" href="../../build/logger/assets/logger.css">
<link type="text/css" rel="stylesheet" href="../../build/datatable/assets/datatable.css">
<link type="text/css" rel="stylesheet" href="./css/examples.css">
<link type="text/css" rel="stylesheet" href="../../docs/assets/dpSyntaxHighlighter.css">
<style type="text/css">
/* custom css*/
#markup {margin:1em;}
#markup table {border-collapse:collapse;}
#markup th {border:1px solid #000;padding:.25em;background-color:#696969;color:#fff;}/*dark gray*/
#markup td {border-bottom:1px solid #000;padding:.25em;}
</style>

<script type="text/javascript" src="../../build/yahoo/yahoo.js"></script>
<script type="text/javascript" src="../../build/dom/dom.js"></script>
<script type="text/javascript" src="../../build/event/event.js"></script>
<script type="text/javascript" src="../../build/datasource/datasource-beta-debug.js"></script>
<script type="text/javascript" src="../../build/datatable/datatable-beta-debug.js"></script>
<script type="text/javascript" src="../../build/logger/logger.js"></script>
</head>
<body>
<script type="text/javascript">
YAHOO.example.enhanceFromMarkup = function() {
    this.columnHeaders = [
        {key:"num",text:"순번",type:"number",sortable:true},
        {key:"bookName",text:"책이름",sortable:true},
        {key:"owners",text:"신청자 명단",type:"html"}
    ];
    this.columnSet = new YAHOO.widget.ColumnSet(this.columnHeaders);

    var markup = YAHOO.util.Dom.get("markup");
    this.dataTable = new YAHOO.widget.DataTable(markup,this.columnSet,null);
};

YAHOO.util.Event.onAvailable("markup",YAHOO.example.enhanceFromMarkup,YAHOO.example.enhanceFromMarkup,true);
</script>
<div id="hd"></div>
<div id="bd">
<div id="markup">
<table id="accounts">
    <thead>
        <tr>
            <th>순번</th>
            <th>책이름</th>
            <th>신청자 명단</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td>1</td>
            <td><a href="http://www.amazon.com/exec/obidos/tg/detail/-/1932394230/ref=ord_cart_shr/103-7860518-9786265?%5Fencoding=UTF8&m=ATVPDKIKX0DER&v=glance">JUnit Recipes: Practical Methods for Programmer Testing</a></td>
            <td>영회</td>
        </tr>
        <tr>
            <td>2</td>
            <td><a href="http://www.amazon.com/exec/obidos/tg/detail/-/1932394885/ref=ord_cart_shr/103-7860518-9786265?%5Fencoding=UTF8&m=ATVPDKIKX0DER&v=glance">Java Persistence with Hibernate</a></td>
            <td>찬욱,기선,한수,계옥,연숙</td>
        </tr>
        <tr>
            <td>3</td>
            <td><a href="http://www.amazon.com/exec/obidos/tg/detail/-/159059584X/ref=ord_cart_shr/103-7860518-9786265?%5Fencoding=UTF8&m=ATVPDKIKX0DER&v=glance">Expert Spring MVC and Web Flow</a></td>
            <td>찬욱</td>
        </tr>
    </tbody>
</table>
</div>
</div>
</body>
</html>

여기서 고정적으로 사용되는 부분이랑 변동 되는 부분을 분리 해내는게 다음 과제가 되겠네요. CustomTag를 활용해서 좀 더 쉽고 간편하게 사용할 수 있는 방법을 찾아야겠습니다.

예제코드 입니다.

'JEDI > YUI' 카테고리의 다른 글

YUI :: DataTable :: 커스텀 태그로 숨기기  (0) 2007.03.20
HTML 태그를 DataTable로  (0) 2007.03.19
YUI :: DataTable :: DataTable 객체 만들기  (0) 2007.03.18
YUI :: DataTable :: DataSource 객체 만들기  (0) 2007.03.18
YUI :: DataTable :: ColumnSet 객체 만들기  (0) 2007.03.18
YUI :: DataTable :: basic.html  (0) 2007.03.18
숙제  (0) 2007.03.17
Yahoo Wideget 개발 준비  (0) 2007.03.15
YUI(Yahoo! UI Library)  (0) 2007.01.22
top

TAG DataTable, YUI

구매 대행 신청 도서 목록 화면

JEDI/ToDo : 2007.03.19 16:22


IE 7
사용자 삽입 이미지
FF
사용자 삽입 이미지
차이 해결 하기.
top


YUI :: DataTable :: DataTable 객체 만들기

JEDI/YUI : 2007.03.18 16:33


앞에서 이미 ColumnSet 객체와 DataSource 객체를 만들었다면 아래에 있는 예제 코드 처럼 만들면 됩니다.
var myDataTable = new YAHOO.widget.DataTable("myContainer", myColumnSet, myDataSource);

그리고 DataTable을 화면에 나타내려면
<div id="myContainer"></div>

이렇게 DataTable의 생성자에 있는 제일 첫번째 인자에 들어가는 String 값과 동일한 id를 가지는 <div>를 추가해주면 됩니다. 그럼 그 부분에 DataTable이 나타나게 됩니다.


'JEDI > YUI' 카테고리의 다른 글

YUI :: DataTable :: 커스텀 태그로 숨기기  (0) 2007.03.20
HTML 태그를 DataTable로  (0) 2007.03.19
YUI :: DataTable :: DataTable 객체 만들기  (0) 2007.03.18
YUI :: DataTable :: DataSource 객체 만들기  (0) 2007.03.18
YUI :: DataTable :: ColumnSet 객체 만들기  (0) 2007.03.18
YUI :: DataTable :: basic.html  (0) 2007.03.18
숙제  (0) 2007.03.17
Yahoo Wideget 개발 준비  (0) 2007.03.15
YUI(Yahoo! UI Library)  (0) 2007.01.22
top

TAG DataTable, YUI

YUI :: DataTable :: DataSource 객체 만들기

JEDI/YUI : 2007.03.18 14:41


참조 : http://developer.yahoo.com/yui/datatable/

흠.. 이 부분이 가장 중요한 부분인데요. 아직 잘 모르겠습니다. 제가 원하는 건 현재 페이지가 List나 자바의 배열 객체를 가지고 있을 때 이것을 어떻게 DataTable로 표현 할 것인가 입니다.

답을 찾을 수 있을지 모르겠지만 일단 ㄱㄱ..

DataTable을 만들기 위해서 DataSource 객체를 만들차례입니다.

var YAHOO.example.puppies = [
  {name:"Ashley",breed:"German Shepherd",age:12},
  {name:"Dirty Harry",breed:"Norwich Terrier",age:5},
  {name:"Emma",breed:"Labrador Retriever",age:9},
  {name:"Oscar",breed:"Yorkshire Terrier",age:6},
  {name:"Riley",breed:"Golden Retriever",age:6},
  {name:"Shannon",breed:"Greyhound",age:12},
  {name:"Washington",breed:"English Bulldog",age:8},
  {name:"Zoe",breed:"Labrador Retriever",age:3}
];

먼저 예제로 보여주는 경우는 DataSource 객체를 만들 때 생성자에 JavaScript 배열이 담긴 파일을 넣어 줍니다.
var myDataSource = new YAHOO.util.DataSource(YAHOO.example.puppies);

그리고 responseType을 JavaScript 배열로 지정해 줍니다.
myDataSource.responseType = YAHOO.util.DataSource.TYPE_JSARRAY;

마지막으로 key에 매핑될 객체의 속성들을 지정해 줍니다.
myDataSource.responseSchema = {
    fields: ["name","breed","age"]
};

responseType으로는 다음과 같은 것들이 있습니다.
TYPE_JSARRAY - final Number :: Type is a JavaScript Array. :: Default Value: 0
TYPE_JSFUNCTIOn - final Number :: Type is a JavaScript Function. :: Default Value: 1
TYPE_JSON - final Number :: Type is JSON. :: Default Value: 3
TYPE_TEXT - final Number :: Type is plain text. :: Default Value: 5
TYPE_UNKNOWN - final Number :: Type is unknown. :: Default Value: -1
TYPE_XHR - final Number :: Type is hosted on a server via an XHR connection. :: Default Value: 2
TYPE_XML - final Number :: Type is XML. :: Default Value: 4

흠...전부 외부 파일로 부터 데이타들을 읽어오는 것 같네요. 흠;;; 매번 이런 파일들을 생성해서 사용할 수도 없고 어떻게 사용하라는거지..ㅠ.ㅠ

request에서 "list" 라는 이름으로 List 객체를 가지고 있을 때 displayTag 같은 경우는   
 <display:table name="list" export="true">
        <display:column property="name" title="이름" href="detail.do" paramId="id" paramProperty="id"/>
        <display:column property="email" autolink="true"/>
        <display:column property="phone" title="연락처"/>
        <display:column property="blogAddress" title="Blog" autolink="true"/>
        <display:column property="messengerId" title="MSN"/>
    </display:table>

이런식으로 쓰면 되는데...흠.. 도무지 감이 잡히질 않는 군요. request에 있는 배열은 DataSource로 어떻게 넣을 수 있지??

<table> 태그로 data들을 표현했다면 DataSource를 만들 필요가 없습니다. DataTable에서 적절하게 매핑할 수 있습니다. 그 방법은 좀이따가 살펴보겠습니다.

jstl 등을 사용해서 <table> 태그를 만들어서 사용해야 되나.. 그렇게 되면 displayTag보다는 불편한거 아닌가.. 흠..;;; 아 머리야; 일단 STOP

'JEDI > YUI' 카테고리의 다른 글

YUI :: DataTable :: 커스텀 태그로 숨기기  (0) 2007.03.20
HTML 태그를 DataTable로  (0) 2007.03.19
YUI :: DataTable :: DataTable 객체 만들기  (0) 2007.03.18
YUI :: DataTable :: DataSource 객체 만들기  (0) 2007.03.18
YUI :: DataTable :: ColumnSet 객체 만들기  (0) 2007.03.18
YUI :: DataTable :: basic.html  (0) 2007.03.18
숙제  (0) 2007.03.17
Yahoo Wideget 개발 준비  (0) 2007.03.15
YUI(Yahoo! UI Library)  (0) 2007.01.22
top


YUI :: DataTable :: ColumnSet 객체 만들기

JEDI/YUI : 2007.03.18 13:44


참조 : http://developer.yahoo.com/yui/datatable/

ColumnSet 의 생성자는 객체의 배열을 받는데 각각의 객체는 DataTable의 맨 위에 해당하는 <TH> 엘리먼트를 나타냅니다.

var myColumnHeaders = [
    {key:"name", text:"Dog's Name"},
    {key:"breed", text:"Dog's Breed"},
    {key:"age", text:"Dog's Age (in Weeks)", type:"number"}
];

var myColumnSet = new YAHOO.widget.ColumnSet(myColumnHeaders);
myColumnHeaders는 배열이고 이 배열을 ColumnSet의 생성자에 넣습니다. 배열의 요소는 Column객체를 나타내며 Column에 지정할 수 있는 속성으로 다음과 같은 것들이 있습니다.

  • abbr - String :: Column head cell ABBR for accessibility.
  • children - Object[] :: Array of object literals that define children (nested headers) of a Column.
  • className - String :: Custom CSS class to be applied to every cell in the Column.
  • currentlyAsc
  • editor - String :: Defines the type of editor for Column, otherwise Column is not editable.
  • formatter - HTMLFunction :: Defines a custom format function for Column, otherwise default is used, according to Column type.
  • key - String :: Associated database field, or null.
  • resizeable - Boolean :: True if Column is resizeable, false otherwise.
    Default Value: false
  • sortable - Boolean :: True if Column is sortable, false otherwise.
    Default Value: false
  • sortOptions.ascFunction - Function :: Custom sort handler to arrange Column in ascending order.
    Default Value: null
  • sortOptions.descFunctio - Function :: Custom sort handler to arrange Column in descending order.
    Default Value: null
  • text - String :: Text or HTML for display in Column's assocated TH element.
  • type - String :: Data types: "string", "number", "date", "currency", "checkbox", "select", "email", "link".
    Default Value: "string"
  • width - String :: Column width

  • abbr이 뭐죠? 흠.. html 태그 중에 하나[각주:1] 였군요. currentlyAcs 속성에 관한건 API에서 찾을 수가 없었습니다. 이 속성들은 다른 예제 코드들을 보면서 차차 익혀가야겠습니다. 흐흐;;

    이전 글에서 보았던 basic.html에 있던 코드의 일부를 다시 보겠습니다.
    var myColumnHeaders = [
        {key:"POID", abbr:"Purchase order ID", sortable:true, resizeable:true},
        {key:"Date", type:"date", sortable:true, resizeable:true},
        {key:"Quantity", type:"number", sortable:true, resizeable:true},
        {key:"Amount", type:"currency", sortable:true, resizeable:true},
        {key:"Title", type:"html", sortable:true, resizeable:true}
    ];

    var myColumnSet = new YAHOO.widget.ColumnSet(myColumnHeaders);

    ColumnSet의 생성자에 넣을 배열의 요소들은 각각이 Column객체이며 그 객체의 속성으로 key, abbr, sortable, resizeable, type 등을 지정했습니다.
    1. 참조를 해보니 축약어에 대한 설명을 달 때 사용하는 태그 였습니다. [본문으로]

    'JEDI > YUI' 카테고리의 다른 글

    YUI :: DataTable :: 커스텀 태그로 숨기기  (0) 2007.03.20
    HTML 태그를 DataTable로  (0) 2007.03.19
    YUI :: DataTable :: DataTable 객체 만들기  (0) 2007.03.18
    YUI :: DataTable :: DataSource 객체 만들기  (0) 2007.03.18
    YUI :: DataTable :: ColumnSet 객체 만들기  (0) 2007.03.18
    YUI :: DataTable :: basic.html  (0) 2007.03.18
    숙제  (0) 2007.03.17
    Yahoo Wideget 개발 준비  (0) 2007.03.15
    YUI(Yahoo! UI Library)  (0) 2007.01.22
    top


    YUI :: DataTable :: basic.html

    JEDI/YUI : 2007.03.18 13:26


    DataTable 예제들

    이 중에서 Basic Table을 자세히 살펴 보겠습니다.

    샘플코드 부분 날리고, Logger 부분을 날리고, CSS 부분도 날리면 다음과 같이 보입니다.
    사용자 삽입 이미지

    핵심 부분의 소스코드는 다음과 같습니다.
    <script type="text/javascript">
    var myColumnHeaders = [
        {key:"POID", abbr:"Purchase order ID", sortable:true, resizeable:true},
        {key:"Date", type:"date", sortable:true, resizeable:true},
        {key:"Quantity", type:"number", sortable:true, resizeable:true},
        {key:"Amount", type:"currency", sortable:true, resizeable:true},
        {key:"Title", type:"html", sortable:true, resizeable:true}
    ];

    var myColumnSet = new YAHOO.widget.ColumnSet(myColumnHeaders);

    var myDataSource = new YAHOO.util.DataSource(YAHOO.example.Data.bookorders);
    myDataSource.responseType = YAHOO.util.DataSource.TYPE_JSARRAY;
    myDataSource.responseSchema = {
        fields: ["POID","Date","Quantity","Amount","Title"]
    };
    var myDataTable = new YAHOO.widget.DataTable("basic", myColumnSet, myDataSource,{caption:"Whiteship: Basic Table"});
    </script>

    먼저 배열로 테이블의 헤더 부분을 지정하고, 그걸로 ColumnSet 객체를 만듭니다.
    다음은 DataSource 객체를 만들고 몇가지 속성을 설정합니다.
    마지막으로 위에서 만든 ColumnSet과 DataSource를 사용해서 DataTable객체를 만들면 됩니다.

    'JEDI > YUI' 카테고리의 다른 글

    YUI :: DataTable :: 커스텀 태그로 숨기기  (0) 2007.03.20
    HTML 태그를 DataTable로  (0) 2007.03.19
    YUI :: DataTable :: DataTable 객체 만들기  (0) 2007.03.18
    YUI :: DataTable :: DataSource 객체 만들기  (0) 2007.03.18
    YUI :: DataTable :: ColumnSet 객체 만들기  (0) 2007.03.18
    YUI :: DataTable :: basic.html  (0) 2007.03.18
    숙제  (0) 2007.03.17
    Yahoo Wideget 개발 준비  (0) 2007.03.15
    YUI(Yahoo! UI Library)  (0) 2007.01.22
    top

    TAG DataTable, YUI

    숙제

    JEDI/YUI : 2007.03.17 00:36


    YUI - DataTable 사용법

    http://developer.yahoo.com/yui/datatable/
    http://www.w3schools.com/js/default.asp

    기한 일요일 오후 5시 전까지...일단 Go to bed..

    'JEDI > YUI' 카테고리의 다른 글

    YUI :: DataTable :: 커스텀 태그로 숨기기  (0) 2007.03.20
    HTML 태그를 DataTable로  (0) 2007.03.19
    YUI :: DataTable :: DataTable 객체 만들기  (0) 2007.03.18
    YUI :: DataTable :: DataSource 객체 만들기  (0) 2007.03.18
    YUI :: DataTable :: ColumnSet 객체 만들기  (0) 2007.03.18
    YUI :: DataTable :: basic.html  (0) 2007.03.18
    숙제  (0) 2007.03.17
    Yahoo Wideget 개발 준비  (0) 2007.03.15
    YUI(Yahoo! UI Library)  (0) 2007.01.22
    top

    TAG YUI

    Yahoo Wideget 개발 준비

    JEDI/YUI : 2007.03.15 14:14


    사용자 삽입 이미지
    위젯 엔진 설치 : http://kr.widget.yahoo.com/down/main.html

    위젯 프로그래밍 레퍼런스(약 300페이지, 한글) : http://img.yahoo.co.kr/widget/2006/12/KR_WidgetEngineReference.pdf

    위젯 튜토리얼(약 30페이지, 한글):
    http://img.yahoo.co.kr/widget/2006/12/KR_WidgetCreationTutorial.pdf

    흐흐 귀여운 위젯 만들어 봅시다~

    'JEDI > YUI' 카테고리의 다른 글

    YUI :: DataTable :: 커스텀 태그로 숨기기  (0) 2007.03.20
    HTML 태그를 DataTable로  (0) 2007.03.19
    YUI :: DataTable :: DataTable 객체 만들기  (0) 2007.03.18
    YUI :: DataTable :: DataSource 객체 만들기  (0) 2007.03.18
    YUI :: DataTable :: ColumnSet 객체 만들기  (0) 2007.03.18
    YUI :: DataTable :: basic.html  (0) 2007.03.18
    숙제  (0) 2007.03.17
    Yahoo Wideget 개발 준비  (0) 2007.03.15
    YUI(Yahoo! UI Library)  (0) 2007.01.22
    top


    YUI(Yahoo! UI Library)

    JEDI/YUI : 2007.01.22 12:52


    http://developer.yahoo.com/yui/
    위에서 javascript와 css를 제공해 줍니다. 구글이나 아마존에서 제공해 주는 공개 API와는 다르게 소스를 직접 다운로드해서 사용할 수 있습니다.

    http://developer.yahoo.com/yui/docs/ <- API

    주소록 프로그램에 유용해 보이는 몇가지 샘플들의 링크를 모아봤습니다.

    http://developer.yahoo.com/yui/examples/container/dialog/2.html
    새로운 멤버나 새로운 그룹 추가를 팝업으로 사용 가능.
    http://developer.yahoo.com/yui/examples/container/simpledialog/2.html
    정말 삭제 하시겠습니까? 또는 수정 하시겠습니까? 라는 팝업으로 사용 가능.
    http://developer.yahoo.com/yui/examples/menu/index.html
    메뉴 만들 때 사용 가능.
    http://developer.yahoo.com/yui/examples/tabview/basic_from_markup.html
    탭뷰로 전체 멤버 보기, 전체 그룹 보기, 회원 추가, 멤버 추가 등의 메뉴 대용으로 사용 가능.
    http://developer.yahoo.com/yui/examples/tabview/transition.html
    탭 전환시 효과가 멋짐.
    http://developer.yahoo.com/yui/grids/#base_markup
    테이블 탬플릿을 위한 CSS를 제공해 줍니다.

    제공 되는 전체 서비스 보기

    more..


    'JEDI > YUI' 카테고리의 다른 글

    YUI :: DataTable :: 커스텀 태그로 숨기기  (0) 2007.03.20
    HTML 태그를 DataTable로  (0) 2007.03.19
    YUI :: DataTable :: DataTable 객체 만들기  (0) 2007.03.18
    YUI :: DataTable :: DataSource 객체 만들기  (0) 2007.03.18
    YUI :: DataTable :: ColumnSet 객체 만들기  (0) 2007.03.18
    YUI :: DataTable :: basic.html  (0) 2007.03.18
    숙제  (0) 2007.03.17
    Yahoo Wideget 개발 준비  (0) 2007.03.15
    YUI(Yahoo! UI Library)  (0) 2007.01.22
    top

    TAG YUI

    AOP 학습 일정 1

    JEDI/ToDo : 2007.01.04 14:35


    2주간 : Spring Reference 6장 공부
    영근님과 온라인에서 발표

    6. Aspect Oriented Programming with Spring
    6.1. Introduction
    6.1.1. AOP concepts
    6.1.2. Spring AOP capabilities and goals
    6.1.3. AOP Proxies in Spring
    6.2. @AspectJ support
    6.2.1. Enabling @AspectJ Support
    6.2.2. Declaring an aspect
    6.2.3. Declaring a pointcut
    6.2.3.1. Supported Pointcut Designators
    6.2.3.2. Combining pointcut expressions
    6.2.3.3. Sharing common pointcut definitions
    6.2.3.4. Examples
    6.2.4. Declaring advice
    6.2.4.1. Before advice
    6.2.4.2. After returning advice
    6.2.4.3. After throwing advice
    6.2.4.4. After (finally) advice
    6.2.4.5. Around advice
    6.2.4.6. Advice parameters
    6.2.4.7. Advice ordering
    6.2.5. Introductions
    6.2.6. Aspect instantiation models
    6.2.7. Example
    6.3. Schema-based AOP support
    6.3.1. Declaring an aspect
    6.3.2. Declaring a pointcut
    6.3.3. Declaring advice
    6.3.3.1. Before advice
    6.3.3.2. After returning advice
    6.3.3.3. After throwing advice
    6.3.3.4. After (finally) advice
    6.3.3.5. Around advice
    6.3.3.6. Advice parameters
    6.3.3.7. Advice ordering
    6.3.4. Introductions
    6.3.5. Aspect instantiation models
    6.3.6. Advisors
    6.3.7. Example
    6.4. Choosing which AOP declaration style to use
    6.4.1. Spring AOP or full AspectJ?
    6.4.2. @AspectJ or XML for Spring AOP?
    6.5. Mixing aspect types
    6.6. Proxying mechanisms
    6.6.1. Understanding AOP proxies
    6.7. Programmatic creation of @AspectJ Proxies
    6.8. Using AspectJ with Spring applications
    6.8.1. Using AspectJ to dependency inject domain objects with Spring
    6.8.1.1. Unit testing @Configurable objects
    6.8.1.2. Working with multiple application contexts
    6.8.2. Other Spring aspects for AspectJ
    6.8.3. Configuring AspectJ aspects using Spring IoC
    6.8.4. Using AspectJ Load-time weaving (LTW) with Spring applications
    6.9. Further Resources
    top


    Building Domain Knowledge

    JEDI/DDD : 2007.01.03 18:39


    비행기 모니터링 시스템을 구축하려고 한다.
    특정 지역에 떠있는 모든 비행기들의 루트를 파악하여 충돌할 가능성이 있는지 나타내는 모니터링 시스템을 구축하는 것이 프로젝트의 목표다.

    앞에서 얘기 했듯이 도메인을 이해하는 것부터 시작해야 한다

    이 분야 도메인 전문가는 비행기 통제사다. 통제사와 대화를 하는 도중 비행기 이륙과 착륙에 대한 이야기를 많이 듣게 되었다. 그리고 실제 충돌이 이착륙 대기 중일 때 발생할 위험이 있다고 한다.

    통제사와 당신은 모든 비행기가 목적지와 출발지가 있다는데에 동의했다. 그래서 다음과 같이 그렸다.

    사용자 삽입 이미지

    실제 비행기가 공중에 있을 때는 어떤 일이 벌어질지 물어본다. 통제사는 각각의 비행기에는 정해진 비행로가 있다고 한다. 대화를 좀더 듣다보니 경로(Route)라는 흥미로운 단어를 들었다. 이 것이 실제 비행중에 가장 중요하다고 생각했고 비행기가 목적지와 출발지와 직접적으로 연관관계를 갖는 것이 아니라 경로(Route)와 연관을 맺고 이 경로가 목적지와 출발지와 연관을 맺도록 하는 좀 더 명확한 표현 같다.
    사용자 삽입 이미지

    좀 더 이야기를 해보니 이 경로는 여러 세부 경로로 나뉘어져 있다는 것을 듣게 된다. 즉 경로가 고정된 포인트로 이루어 진 것으로 파악이 되며 목적지와 출발지는 그 고정된 포인트 중 두 개로 파악할 수 있다.
    사용자 삽입 이미지
    고정된 위치는 3차원으로 표기 할 수 있다.(경도, 위도, 고도?) 하지만 통제사는 비행기를 지구 표면의 평면으로 투사한 곳에 점으로 인식하고 있다는 것을 알게 됐다. 따라서 2차원 점(경도 , 위도만?)으로 표현되도록 수정하였다.
    사용자 삽입 이미지


    여기까지 진행 한 것을 살펴보면 굉장히 많은 시간을 소비하는 것처럼 보이고 실제로도 그렇치만 당연히 이렇게 해야만 한다. 소프트웨어의 최종 목적은 현실의 도메인과 관련된 비즈니스 문제를 해결하는 것이기 때문에 도메인에 익숙해 져야한다.

    'JEDI > DDD' 카테고리의 다른 글

    [DDD] DDD 입문에 좋은 글  (4) 2009.06.11
    파트 3: Refactoring Toward Deeper Insight  (0) 2008.10.24
    Factories  (0) 2007.12.25
    Aggregates  (0) 2007.12.18
    Modules  (2) 2007.12.14
    Services  (2) 2007.12.13
    DAO vs Repository  (4) 2007.12.04
    DTO(Data Transfer Object)  (2) 2007.11.21
    DDD: putting the model to work  (4) 2007.11.20
    Building Domain Knowledge  (0) 2007.01.03
    What Is Domain-Driven Design  (2) 2007.01.02
    top

    TAG DDD