기능이 아니라 구조를 기반으로 모델을 구축하는 편이 좀 더 범용적이고 이해하기 쉬우며 변경에 안정적 # 기능 설계 VS 구조 설계 기능 설계 : 제품이 사용자를 위해 무엇을 할 수 있는가 구조 설계 : 제품의 형태가 어떠해야 하는가 훌륭한 기능은 충분조건, 훌륭한 구조는 필요조건 우리는 미래를 예측할 수 없다, 단지 대비할 수 있을 뿐 훌륭한 SW는 좋은 기능을 제공하면서 변경에 유연 좋은 설계는 병결할 수 있는 여지를 남겨 놓는 설계 변경의 여지를 남겨 놓는 가장 좋은 방법은 자주 변경되는 기능이 아닌 안정적인 구조를 중심으로 설계하는 것 # 객체지향 설계 기법 구조는 사용자나 이해관계자들이 도메인에 관해 생각하는 개념과 개념들 간의 관계로 표현 : 도메인 모델링 기능은 사용자의 목표를 만족시키기 위해..

# DB 중심 아키텍처 문제점 DB 중심 아키텍처 : 특정 RDB에 의존한 데이터 모델링을 수행한 다음 이 물리 테이블 모델을 중심에 두고 APP을 구현하기 위한 사고를 하는 방식 - 간단한 처리 로직은 편하나, 업무가 복잡해지면 점점 복잡성을 제어할 수 없음 - DB에 의존하게 되어 스케일 아웃 성능이 떨어짐 # 레이어드 아키텍처 프레젠테이션, 비즈니스로직, 데이터 엑세스 3계층으로 구분하는 것이 일반적 ## 레이어드 아키텍처 규칙 - 상위 계층이 하위 계층을 호출하는 단방향성 유지 - 바로 밑의 근접 계층만 활용 - 상위 계층이 하위 계층에게 영향 받지 않게 구성 - 하위 계층은 자신을 사용하는 상위 계층을 알지 못하게 구성 - 계층 간의 호출은 인터페이스를 통해 호출(의존성 분리) 현대 APP은 다..