3-Layer Architecture?
소프트웨어 개발에서 자주 사용하는 3-Layer Architecture는 애플리케이션을 크게 세 부분으로 나누어 설계하는 방법이다. 이 구조는 프레젠테이션 계층(Presentation Layer), 비즈니스 로직 계층(Business Logic Layer), 데이터 접근 계층(Data Access Layer)으로 이루어져 있다. 각 계층이 맡은 역할을 분리해 줌으로써 유지보수와 확장성을 높이는 데 도움을 준다.
1. 프레젠테이션 계층(Controller)
이 부분은 사용자 인터페이스(UI)와 관련된다. 사용자가 애플리케이션과 상호작용하는 부분이며, 입력된 데이터를 받아 다음 계층으로 전달한다. (수문장 역할)
2. 비즈니스 로직 계층(Serviece)
이 계층은 애플리케이션의 핵심 로직을 처리한다. 규칙을 적용하고 데이터를 계산하며, 사용자 요청을 실제로 처리하는 역할을 한다.
3. 데이터 접근 계층(Repository)
데이터베이스와의 상호작용을 담당하는 부분이다. 데이터를 생성, 읽기, 수정, 삭제(CRUD)하며, 비즈니스 로직 계층이 필요한 데이터를 제공한다.
왜 3-Layer Architecture가 필요할까?
1. 유지보수성 향상:
각 계층이 독립적으로 작동하기 때문에, 코드 변경이 필요할 때 다른 계층에 미치는 영향을 최소화할 수 있다.
2. 코드 재사용성:
비즈니스 로직과 데이터 접근 계층은 여러 프레젠테이션 계층에서 재사용할 수 있다.
3. 테스트 용이성:
각 계층별로 독립적으로 테스트를 진행할 수 있어, 버그를 조기에 발견하고 수정할 수 있다.
유용한 점
1. 개발 효율성:
여러 팀이 동시에 다른 계층을 개발할 수 있어, 개발 속도가 빨라진다.
2. 유지보수 비용 절감:
계층별로 독립적인 수정이 가능해, 유지보수 비용을 줄일 수 있다.
3. 확장성:
새로운 기능을 추가하거나 변경할 때, 특정 계층만 수정하면 되어 시스템 확장이 용이하다.
주의할 점
1. 복잡성 증가:
작은 프로젝트에 이 구조를 도입하면 오히려 복잡해질 수 있습니다. 프로젝트 규모에 맞게 사용하는 것이 중요하다.
2. 성능 문제:
계층 간의 호출이 많아지면 성능이 저하될 수 있으니, 최적화가 필요하다.
결론
3-Layer Architecture는 소프트웨어의 유지보수성, 확장성, 테스트 용이성을 높이는 데 매우 유용한 설계 패턴이다. 하지만, 모든 프로젝트에 동일하게 적용할 수 있는 것은 아니므로, 프로젝트의 규모와 특성을 고려하여 적절히 활용해야 한다. 이를 통해 보다 안정적이고 효율적인 소프트웨어를 개발할 수 있을 것이다.
활용
코드
https://github.com/Sangmin1999/schedule/commit/39c7ea094cdb657ca847898f95801d460df9f890
느낀점
이번에 클래스를 service와 repository로 나누는 작업을 진행하면서, 각 코드가 어떤 기능을 하는지 알기도 편하고 보기에도 쉬워진 것 같아서 유지보수성이 높아진 것을 많이 느낄 수 있었다. 이번 과제에서는 모든 코드를 작성한 후 나누는 작업을 하였지만, 다음부터는 처음부터 기능대로 나누면서 작업을 하면 스스로 어떤 기능을 작업하고 오류가 나면 어디서 오류가 발생했는지 알기 쉬울 것 같다.
