시작하며

• 가상의 송금 서비스 Buckpal 을 만드는 걸로 시작한다.
• 이 서비스는 아래와 같은 기능들을 한다
  • 계좌를 생성할 수 있다
  • 한 계좌에서 다른 계좌로 송금할 수 있다
  • 한 계좌의 입/출금 내역을 확인할 수 있다
• 저자의 Buckpal 을 Java 로 구현한 예제 코드는 여기서 살펴볼 수 있다.
• 참고사항
  • Java 로 구현되어 있지만, Java 코드를 어느정도 읽을 줄만 안다면 Java 외의 OOP Language 를 사용하여도 상관없다

Whats wrong with layers?

About layered architecture

• 우리가 익히 알고있는 layered architecture 를 돌아보자, 해당 architecture 는

  • web: network 를 통한 요청을 받아, 그걸 domain layer 에 넘겨준다
  • domain(AKA business): 필요한 일들을 처리하고, persistence layer 에서 필요한 구성요소들을 호출하여 domain entity 의 필요한 부분을 가져오거나(query) 혹은 수정하는(modify) 역할을 한다
  • persistence: domain layer 의 요청에 따라 domain entity 의 state 를 가져오거나 수정하는걸 도와준다

  라는 계층으로 구성되어있다

• 물론 이 layered architecture 도 사실은 solid(강건한) architecture pattern 이다. ‘잘만 구현한다면' 우리는 web layer 혹은 persistence layer 와 독립적으로 domain layer 를 구현할 수 있다.

  • 다시 말 해서, web layer 나 persistence layer 를 구성하는 기술이 바뀌어도 domain layer 는 전혀 상관이 없다는 이야기이다, ‘잘만 짜면'.

• 그렇게 되는 만큼, domain layer 에 새로운 기능을 추가하는 것도 쉬워진다

Whats wrong with it?

• 저자의 경험에 따르면 layered architecture 는 헛점(flank)들이 좀 있고, 그 헛점들은 시간이 지나면 지날수록 변화하기 어려운 시스템을 만들게끔 한다고 한다.

Database-driven design

• 가장 먼저, 이 전통적인 layered architecture 의 핵심이 database 라는 점이 문제점을 만든다.
  • state 라는 건, behavior 의 부수적인 결과물인데, 해당 architecture 의 foundation 이 persistence layer, 즉 database 이고, 이 persistence layer 는 domain entity 의 state 를 저장하고 / 가져오고 / 수정하는 것 뿐인데, 이렇게 되다보니 우리는 너무 state 에 묶여서 생각하게 된다. 결국 본질은 behavior 인데 말이다.
  • 우리가 어떤 시스템을 구현할 때를 생각해보자. 높은 확률로 먼저 database 의 structure 를 생각할 것이고, 그것에 맞추어 domain logic 을 구현할 것이다.
• domain logic 을 먼저 만들고, persistence layer 와 web layer 를 만드는 것이 순서에 더 맞을텐데 말이다.

• 그리고 ORM(Object Relation Mapper) 이라는 도구가 나오면서 이 경향은 더욱 심해졌다, 우리가 layered architecture 를 ORM 을 통해 구현하면 business rule 과 persistence aspect 를 섞어버리기 쉽다.