티스토리 뷰

원문 : http://martinfowler.com/bliki/PresentationDomainDataLayering.html


information-rich 프로그램을 모듈화하는 잘 알려진 방법 중 하나는 세 가지 layer로 분리하는 것이다. : presentation(UI), domain logic(aka business logic), data access. 그래서 http Request들을 처리하는 것과 HTML을 렌더링 하는 것, 검증과 계산을 하는 비지니스 로직, 데이터베이스나 원격 서비스에 잔류하는 데이터들을 관리하기 위한 처리를 하는 data access로 웹 레이어가 나뉘어진 웹 어플리케이션을 종종 보게 될 것이다. 





대체로 많은 어플리케이션들을 위한 모듈화의 효과적인 형식을 발견했었고 그것을 정기적으로 사용하고 권장했다. (나에게 있어서) 가장 큰 장점은 세가지 주제를 비교적 독립적으로 생각할 수 있게 해주어서 내가 주의를 기울일 수 있는 범위를 축소 시킬 수 있도록 해주었다. 


 도메인 로직 코드를 작성할 때는 UI를 대부분 무시할 수 있고, 내가 필요로 하는 데이터를 건내주는 추상적인 함수를 사용하기만 하면 data source와 상호작용할 수 있고 내가 바라는 것을 갱신할 수 있다. data access 레이어에서 작업을 할때는 인터페이스로부터 요청되는 폼 안의 데이터에 대한 wrangling의 디테일에 집중한다. presentation 작업을 할때는 UI 행동에 집중 하거나 어떤 데이터에 대해 display하거나 함수 호출로 인한 마술 같은 update를 할 수 있다.  이러한 요소를 분리함으로써 내가 해야만 하는 것들을 더 쉽게 만드는 각각의 조각들로 내 생각의 범위를 좁힌다.


범위를 좁힌다는 것은 프로그래밍을 위한 어떠한 절차에도 나타나지 않는다. (나는 보통 레이어들 사이를 반복해야만 찾는다.) 나는 UX의 초반 이해를 위해 data와 domain 레이어들을 빌드 했었지만 UX refining 할 때 data 레이어로 변경이 필요한 도메인을 변경해야 한다. 그러나 cross-layer와 같은 종류의 반복에서 조차 내가 변화시킨 것을 단번에 어느 레이어에서든 요점을 쉽게 발견했다. 이는 refactoring's two hats에서 본것과 같은 생각의 전환과 비슷하다. 


모듈화의 다른 이유는 모듈들의 다른 구현을 대체 할 수 있도록 하는 것이다.  이 구분은 중복 없이 동일한 domain logic 위에 다수의 presentation들을 빌드하도록 한다. 다수의 presentation들은 web app이나 web app 을 추가로 가지고 있는 모바일 네이티브 앱들이나 scripting 성능을 위한 API들 또는 구식의 command line 인터페이스에서 페이지들로 구분될 수도 있다.

data source를 모듈화하여 database 기술의 변화에 적절하게 대처하거나 약간의 알림으로 변화 할 수도 있는 지속성 서비스들을 지원할 수 있다. 그러나 나는 종종 data source layer를 구분하는 driver인 data access substitution에 대해 듣는 동안 드물게 몇몇 사람들에게 그것을 정말로 사용한다는 것을 언급 해야만 한다. 


아직 번역 중...


on the whole : 전체적으로 보아, 대체로

reduce : 줄이다.

attention : 주의, 주목

relatively : 비교적

treat : 대하다, 여기다, 처리하다.

interaction : 상호작용

wrangling : 논쟁

imply : 넌지시 나타내다, 암시하다, 의미하다.

need to : 해야만 한다.

refining : 정제, 조제

necessitate : ~을 필요하게 만들다.

substitute : 대신하는 사람[것], 대신하다, 교체되다.

fashioned : ~식의, ~풍의

could be : ~될 수도 있다.

cope : 대처하다, 대응하다.

persist : 계속되다, 지속되다.


might 는 may의 과거형으로 특별한 의미가 아니더라도 과거를 나타낼 때 사용한다. 



댓글
댓글쓰기 폼