<div id="readability-page-1" class="page">





<div id="wrap">
	
	<hr>
	<section>
		<article id="content">

			

			

			

			

			<div>
				

				
					
					
						<div>
							<p>소프트웨어-이야기/아키텍처</p>
							<h2>레이어드 아키텍처 </h2>
							<p>
								<span>2022. 4. 10. 23:12</span>
								
							</p>
						</div>
						<div><figure data-origin-width="1376" data-origin-height="1138" data-ke-mobilestyle="alignCenter"><span data-url="https://blog.kakaocdn.net/dn/bdN9k6/btryY9CYmkY/CpcIoAK2yjH6EMnQDR5Ar1/img.png" data-lightbox="lightbox" data-alt="https://www.oreilly.com/content/software-architecture-patterns/"><img src="https://blog.kakaocdn.net/dn/bdN9k6/btryY9CYmkY/CpcIoAK2yjH6EMnQDR5Ar1/img.png" width="600" height="496" data-filename="sapr_0103-4f24e5296562ca836bcf3a1669041f08.png" data-ke-mobilestyle="alignCenter"></span><figcaption>https://www.oreilly.com/content/software-architecture-patterns/</figcaption></figure>

<p data-ke-size="size16">레이어드 아키텍처 (n티어 아키텍처)는 일반적으로 많이 사용되는 아키텍처이다. 더 나은 아키텍처 대안을 찾지 못할 때, 쉽게 선택하는 아키텍처 패턴이다.&nbsp;</p>
<p data-ke-size="size16">Spring Project에서 각 레이어는 다음과 같은 클래스로 구현된다.</p>
<ul data-ke-list-type="disc">
<li>Presentation Layer : Controller</li>
<li>Business Layer : Service</li>
<li>Persistence Layer : Entity</li>
<li>Database Layer : Repository&nbsp;</li>
</ul>
<p data-ke-size="size16"><b>특징</b></p>
<p data-ke-size="size16">레이어드 아키텍처는 작고 간단한 서비스를 만들 때, 출발점으로 적합한 아키텍처다.</p>
<p data-ke-size="size16">개발자에게 익숙하고, 복잡도도 낮기 때문에 소규모 애플리케이션에 적합하다.</p>
<p data-ke-size="size16"><b>단점</b></p>
<ul data-ke-list-type="circle">
<li>계층형 아키텍처는 영속성 계층을 토대로 만들어지기 때문에, 데이터베이스 주도 설계를 유도한다.
<ul data-ke-list-type="disc">
<li>계층형 아키텍처에서 ORM 프레임워크를 사용하면, 데이터베이스 중심적인 아키텍처가 되기 쉽다.</li>
<li>영속성 계층에 비즈니스 로직을 추가하고 싶어지기 때문이다.&nbsp;</li>
<li>혹은 비즈니스 계층에서 영속성 모델을 비즈니스 모델처럼 사용하게 되어, 비즈니스 계층에 영속성 계층에 대한 로직이 추가될 수도 있다.&nbsp;</li>
</ul>
</li>
<li>상위 계층에 있는 컴포넌트가 필요한 경우, 컴포넌트를 아래로 내려서 문제를 해결하는 경우가 있다.
<ul data-ke-list-type="disc">
<li>이 경우, 영속성 계층 (최하단)이 비대해질 수 있다.</li>
<li>상위 계층에서 영속성 계층을 계속 참조하면, 하나의 코드 수정 범위가 넓어질 수 있다.</li>
</ul>
</li>
<li>상위 레이어에서 하위 레이어에 직접 접근하는 코드가 늘어나, 테스트를 하기 어려워질 수 있다.
<ul data-ke-list-type="disc">
<li>예를 들어, 컨트롤러에서 직접 엔티티와 리포지토리를 조회하는 경우가 생길 수도 있다.</li>
</ul>
</li>
<li>하나의 서비스를 여러 컨트롤러에서 사용하게 되어, 유스케이스를 유추하기 어렵게 만든다.</li>
<li>동시 작업이 어렵다.&nbsp;</li>
</ul>
<p data-ke-size="size16">때문에 레이어드 아키텍처는 규모가 커질 수록 유지 보수가 어려워진다.</p>
<p data-ke-size="size16">대규모 애플리케이션에서는 더 모듈화된 아키텍처가 적합하다.&nbsp;</p>

<p data-ke-size="size16"><b>고려사항</b></p>
<p data-ke-size="size16">레이어드 아키텍처에서는 싱크홀 안티패턴을 조심해야한다.&nbsp;</p>
<p data-ke-size="size16">요청이 한 레이어에서 다른 레이어로 이동할 때, 각 레이어가 아무 비즈니스 로직도 처리하지 않고 그냥 통과시키는 패턴을 말한다.</p>


<h4 data-ke-size="size20">참고</h4>
<p data-ke-size="size16">소프트웨어 아키텍처 101</p>
<p data-ke-size="size16">만들면서 배우는 클린 아키텍처</p></div>
						

						
							<div>
								<h2><strong>'소프트웨어-이야기/아키텍처'</strong> Related Articles</h2>
								
							</div>
						

						

					
				
			</div>

			

			

			
				
			

		</article>
	</section>
	<hr>
	
</div>




	            
            
            
                        
                        
                                       
                                               
        

</div>

복세편살

레이어드 아키텍처 (n티어 아키텍처)는 일반적으로 많이 사용되는 아키텍처이다. 더 나은 아키텍처 대안을 찾지 못할 때, 쉽게 선택하는 아키텍처 패턴이다. 
Spring Project에서 각 레이어는 다음과 같은 클래스로 구현된다.
Presentation Layer : Controller
Business Layer : Service
Persistence Layer : Entity
Database Layer : Repository 
특징
레이어드 아키텍처는 작고 간단한 서비스를 만들 때, 출발점으로 적합한 아키텍처다.
개발자에게 익숙하고, 복잡도도 낮기 때문에 소규모 애플리케이션에 적합하다.
단점
계층형 아키텍처는 영속성 계층을 토대로 만들어지기 때문에, 데이터베이스 주도 설계를 유도한다.
계층형 아키텍처에서 ORM 프레임워크를 사용하면, 데이터베이스 중심적인 아키텍처가 되기 쉽다.
영속성 계층에 비즈니스 로직을 추가하고 싶어지기 때문이다. 
혹은 비즈니스 계층에서 영속성 모델을 비즈니스 모델처럼 사용하게 되어, 비즈니스 계층에 영속성 계층에 대한 로직이 추가될 수도 있다. 
상위 계층에 있는 컴포넌트가 필요한 경우, 컴포넌트를 아래로 내려서 문제를 해결하는 경우가 있다.
이 경우, 영속성 계층 (최하단)이 비대해질 수 있다.
상위 계층에서 영속성 계층을 계속 참조하면, 하나의 코드 수정 범위가 넓어질 수 있다.
상위 레이어에서 하위 레이어에 직접 접근하는 코드가 늘어나, 테스트를 하기 어려워질 수 있다.
예를 들어, 컨트롤러에서 직접 엔티티와 리포지토리를 조회하는 경우가 생길 수도 있다.
하나의 서비스를 여러 컨트롤러에서 사용하게 되어, 유스케이스를 유추하기 어렵게 만든다.
동시 작업이 어렵다. 
때문에 레이어드 아키텍처는 규모가 커질 수록 유지 보수가 어려워진다.
대규모 애플리케이션에서는 더 모듈화된 아키텍처가 적합하다. 
 
고려사항
레이어드 아키텍처에서는 싱크홀 안티패턴을 조심해야한다. 
요청이 한 레이어에서 다른 레이어로 이동할 때, 각 레이어가 아무 비즈니스 로직도 처리하지 않고 그냥 통과시키는 패턴을 말한다.
 
 
참고
소프트웨어 아키텍처 101
만들면서 배우는 클린 아키텍처

레이어드 아키텍처

댓글