<div id="readability-page-1" class="page"><div id="entry-view">
      
      <main>
        <div>
            <article id="mainContent">
              <div>
                <p><a href="/m/category/TIL/%EC%84%B8%EB%AF%B8%EB%82%98"><span>TIL/세미나</span></a></p><h3>[우아콘 2022] 기획자님들! 개발자가 아키텍처에 집착하는 이유 쉽게 알려드립니다.</h3>
              </div>
              <p><cite>Seyun(Marco)</cite>
                <span> 2024. 1. 7. 11:07</span>
              </p>
                              <div>
                                <p data-ke-size="size16">💡 원본 영상 : <a href="https://youtu.be/saxHxoUeeSw?si=Gg1FrAHEgiUKg6U2">https://youtu.be/saxHxoUeeSw?si=Gg1FrAHEgiUKg6U2</a></p>
<figure data-ke-type="video" data-ke-style="alignCenter" data-video-host="youtube" data-video-url="https://www.youtube.com/watch?v=saxHxoUeeSw" data-video-thumbnail="https://scrap.kakaocdn.net/dn/cEIwdN/hyUXOxopO0/PqfH2nSkonGMxqNQY8cgLK/img.jpg?width=1280&amp;height=720&amp;face=930_160_1046_288" data-video-width="860" data-video-height="484" data-video-origin-width="860" data-video-origin-height="484" data-ke-mobilestyle="widthContent" data-original-url="" data-video-title=""><iframe src="https://www.youtube.com/embed/saxHxoUeeSw" width="860" height="484" frameborder="" allowfullscreen=""></iframe>

<img src="https://scrap.kakaocdn.net/dn/cEIwdN/hyUXOxopO0/PqfH2nSkonGMxqNQY8cgLK/img.jpg?width=1280&amp;height=720&amp;face=930_160_1046_288"></figure>
<h2 data-ke-size="size26">세미나 내용</h2>
<ul data-ke-list-type="disc">
<li>여기서 다룰 내용은 아래와 같습니다
<ul data-ke-list-type="disc">
<li>소프트웨어 아키텍처의 목적</li>
<li>클린 아키텍처와 헥사고날 아키텍처</li>
<li>아키텍처의 목표</li>
</ul>
</li>
<li>이 발표를 하는 이유는 개발자들의 용어를 기획자(PM/PO) 분들이 알았으면 좋을거 같고, 기획자의 목표와 개발자의 목표가 같은 곳을 바라보고 있다는 것을 알려주고 싶었다.</li>
</ul>
<figure data-ke-mobilestyle="widthOrigin" data-origin-width="1540" data-origin-height="896">
    <span data-url="https://blog.kakaocdn.net/dn/zvtvo/btsC8XYMjIm/bcOfz5YW6B3hpvjnV8O6tk/img.png" data-lightbox="lightbox">
        <img src="https://blog.kakaocdn.net/dn/zvtvo/btsC8XYMjIm/bcOfz5YW6B3hpvjnV8O6tk/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-origin-width="1540" data-origin-height="896">
    </span>
    
</figure>
<ul data-ke-list-type="disc">
<li>소프트웨어는 복잡합니다. 얽히고 얽힌 코드들로 구성되어 있습니다. 따라서 주기적으로 변경이 필요한데요. 위의 사진을 소프트웨어라고 생각한다면 여기서 가위를 칼로 변경해야 한다면 어떻게 해야 할까요? <b>끈으로 연결되어 있는 다른 도구들의 연결들을 풀고 가위를 칼로 변경하고 다시 연결</b>해줘야 합니다. 이때 갑자기 펜이 다시 가위가 필요해! 라고 한다면, 다시 펜과 가위를 연결하고 이 연결들이 모두 연쇄적으로 영향을 주게 됩니다.</li>
<li>이렇게 되면, 무언가를 변경하고, 추가하려고 하면 굉장히 시간이 오래걸리고 파악하기가 어렵습니다.</li>
</ul>
<figure data-ke-mobilestyle="widthOrigin" data-origin-width="1058" data-origin-height="758">
    <span data-url="https://blog.kakaocdn.net/dn/7DnBM/btsC38UM6P0/AgTtmXDYVxfDZuA9Tv6IU0/img.png" data-lightbox="lightbox">
        <img src="https://blog.kakaocdn.net/dn/7DnBM/btsC38UM6P0/AgTtmXDYVxfDZuA9Tv6IU0/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-origin-width="1058" data-origin-height="758">
    </span>
    
</figure>
<ul data-ke-list-type="disc">
<li>다시 위의 사진을 봅시다. 서로 끈으로 연결되어 있지 않고, 포스트잇으로만 모두 연결되어 있는걸 확인할 수 있습니다. 이때 가위를 칼로 변경하려고 할때, 다른 도구들은 신경쓰지 않고 가위를 칼로 변경하면 됩니다. 즉, 변경하기도 쉽고 실제 무언가를 추가하는것도 쉬운거죠. 이걸 <b>클린 아키텍처</b>라고 합니다.</li>
<li>이 과정에서 아키텍처의 목표를 알수가 있는데요. 즉, <b>소프트웨어를 쉽게 변경할 수 있게 해서 유지보수를 쉽게 하는 것입니다.</b></li>
<li>그러나 클린 아키텍처라고 보여지는 사진에서 문제가 아직 남아 있긴 합니다. 바로 포스트잇을 변경해야 한다면 어떻게 해야 할까요? 이걸 개발 영역에선 의존성이라고 말하빈다.</li>
<li>조금 간단히 도식화를 해보면 아래 사진과 같습니다.</li>
<li>조금 간단히 도식화 해보면 아래와 같습니다.</li>
</ul>
<figure data-ke-mobilestyle="widthOrigin" data-origin-width="828" data-origin-height="718">
    <span data-url="https://blog.kakaocdn.net/dn/cttuhK/btsC4eHuTIg/xiUtTSo5MwJTpYXn2c2MTk/img.png" data-lightbox="lightbox">
        <img src="https://blog.kakaocdn.net/dn/cttuhK/btsC4eHuTIg/xiUtTSo5MwJTpYXn2c2MTk/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-origin-width="828" data-origin-height="718">
    </span>
    
</figure>
<ul data-ke-list-type="disc">
<li>여기서 포스트잇이 도메인 / 나머지가 인프라스트럭처입니다.</li>
</ul>
<blockquote data-ke-style="style1">
<p data-ke-size="size16"><b><span>여기서 도메인이란?</span></b><span>소프트웨어를 이루고자 하는 핵심적인 요소를 말합니다. 예를들어, 해당 발표에선 주문접수 프로세스, 정책 등에 로직이 주문접수 도메인에 포함될것입니다.</span><b>그렇다면 인프라스트럭처는?</b><span>도메인을 소프트웨어로 제공하기 위한 기능으로 DB, UI, 외부 API 등등을 의미합니다.</span></p>
</blockquote>
<ul data-ke-list-type="disc">
<li>지금 그림에서 도메인과 인프라스트럭처는 무수히 많은 선(의존성)이 존재하게 됩니다.</li>
<li>여기서 도메인이란? 소프트웨어로 이루고자 하는 핵심적인 요소를 말한다.
<ul data-ke-list-type="disc">
<li>도메인을 소프트웨어로 제공하기 위한 기능
<ul data-ke-list-type="disc">
<li>DB, UI, 외부 API 등등</li>
</ul>
</li>
</ul>
</li>
<li>도메인과 인프라스트럭처와 무수히 많은 선, 의존성이 존재한다.</li>
</ul>
<figure data-ke-mobilestyle="widthOrigin" data-origin-width="1552" data-origin-height="694">
    <span data-url="https://blog.kakaocdn.net/dn/eaiCqr/btsC8RdbFUh/GwKwHiHP5wMiDBWb6jKcA1/img.png" data-lightbox="lightbox">
        <img src="https://blog.kakaocdn.net/dn/eaiCqr/btsC8RdbFUh/GwKwHiHP5wMiDBWb6jKcA1/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-origin-width="1552" data-origin-height="694">
    </span>
    
</figure>
<ul data-ke-list-type="disc">
<li>그럼 이제 사용하고 있는 계층형 아키텍처를 보면, 몇가지 문제점이 있게 됩니다.</li>
<li>프리젠테이션 계층이 도메인 계층과 의존되어 있고 도메인 계층은 영속성 계층을 의존하고 있습니다. 즉, 프리젠테이션도 영속성 계층과 의존이 있는거죠. 이렇게 연쇄적인 참조 관계입니다.</li>
</ul>
<figure data-ke-mobilestyle="widthOrigin" data-origin-width="1544" data-origin-height="756">
    <span data-url="https://blog.kakaocdn.net/dn/bttvMg/btsC31uDsyy/BkunKcz5DzN0JgLkBTkNAk/img.png" data-lightbox="lightbox">
        <img src="https://blog.kakaocdn.net/dn/bttvMg/btsC31uDsyy/BkunKcz5DzN0JgLkBTkNAk/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-origin-width="1544" data-origin-height="756">
    </span>
    
</figure>
<ul data-ke-list-type="disc">
<li>의존성이 있다는 것이 변경의 영향을 받는다는 것이고 이렇게 의존성을 가지면 코드를 추가하거나 변경하는게 어려움이 생기게 됩니다. 또한 테스트를 하기도 어렵게 됩니다.</li>
<li>또한, 도메인 계층이 프리젠테이션 계층 / 영속성 계층에 영향을 너무 받게 됩니다. 핵심적인 부분이 다른 영향을 많이 받기 때문에 문제가 생길수도 있습니다. 따라서 도메인 계층을 잘 보호해야 합니다.</li>
<li>따라서 중요한 도메인 계층을 잘 보호해야 합니다.</li>
</ul>
<figure data-ke-mobilestyle="widthOrigin" data-origin-width="1354" data-origin-height="902">
    <span data-url="https://blog.kakaocdn.net/dn/5kX21/btsC7oPWwfz/Kbj1TBDgNBRj4ujQcQ7jTK/img.png" data-lightbox="lightbox">
        <img src="https://blog.kakaocdn.net/dn/5kX21/btsC7oPWwfz/Kbj1TBDgNBRj4ujQcQ7jTK/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-origin-width="1354" data-origin-height="902">
    </span>
    
</figure>
<ul data-ke-list-type="disc">
<li>그렇다면 이제 클린 아키텍처의 헥사고날 아키텍처를 보도록 하겠습니다. 실제 위 사진에 보면, 화살펴고 원 안쪽으로 향하는것을 알수 있습니다. 이것을 하부사항들이 고수준 사항들의 방향으로 단방향으로 의존하는것을 알수가 있습니다. 이런 방향이 되는 이유는 아키텍처가 무엇을 보호하고 집중하는지 보여지기 위함인데, 보면 Entities와 Use case인 도메인을 보호하기 위함입니다.</li>
</ul>
<figure data-ke-mobilestyle="widthOrigin" data-origin-width="1514" data-origin-height="736">
    <span data-url="https://blog.kakaocdn.net/dn/Pky01/btsC4aSFiFZ/S9EMYTn8vWPqeq94PkKKK1/img.png" data-lightbox="lightbox">
        <img src="https://blog.kakaocdn.net/dn/Pky01/btsC4aSFiFZ/S9EMYTn8vWPqeq94PkKKK1/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-origin-width="1514" data-origin-height="736">
    </span>
    
</figure>
<ul data-ke-list-type="disc">
<li>이걸 다른 도식화로 보면, 도메인 영역이 각 프리젠테이션과 영속성 계층이 안으로 화살표를 바라보게 되는걸 알수 있습니다. 또한 그 부분에서 어댑터(Presenter)가 있는것을 알수 있습니다.</li>
<li>여기서 어댑터란? 전원 어댑터를 생각하면 됩니다. 외부의 데이터 흐름을 내부 데이터로 사용 할 수 있도록 하는, 어댑터만 맞으면 영속성이나 프리젠테이션 영역이 변경되는것에 대해서 문제가 되지 않는 방식입니다. 또한 Repository의 방향은 프리젠테이션과 반대로 되어 있는걸 알수 있는데 이게 바로 의존성 역전이고 인터페이스로 구현이 가능합니다.</li>
<li>어댑터가 도메인을 의존하는 방향이 안쪽을 향하고 있다. 특히 Repository는 방향이 반대로 한다.</li>
<li>이걸 할 수있는 것이 의존성 역전이고, 인터페이스(약속)로 구현가능하다.</li>
</ul>
<figure data-ke-mobilestyle="widthOrigin" data-origin-width="1560" data-origin-height="806">
    <span data-url="https://blog.kakaocdn.net/dn/wlZKV/btsC4cXebad/75thX6cSkP40K3z7hW65tK/img.png" data-lightbox="lightbox">
        <img src="https://blog.kakaocdn.net/dn/wlZKV/btsC4cXebad/75thX6cSkP40K3z7hW65tK/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-origin-width="1560" data-origin-height="806">
    </span>
    
</figure>
<ul data-ke-list-type="disc">
<li>이러한 구조 장점
<ul data-ke-list-type="disc">
<li>세부사항 변경시 도메인이 영향받지 않습니다.</li>
<li>밖의 세부사항을 손쉽게 변경이 가능하다. 도메인 양측의 약속만 잘 지킨다면 변경이 쉽다.</li>
<li>의존성을 낮추면 각 요소를 독립적으로 테스트가 가능하다.</li>
<li>테스트 데이터가 필요한 경우 인터페이스만 맞춘다면 테스트 데이터로 사용 가능하다.</li>
</ul>
</li>
<li>여기서 가장 중요한것은 세부사항 변경시 도메인이 영향받지 않는다는 점입니다.</li>
</ul>
<figure data-ke-mobilestyle="widthOrigin" data-origin-width="1646" data-origin-height="886">
    <span data-url="https://blog.kakaocdn.net/dn/by0qd7/btsC4CH6n47/UsUqv187HBKON8RQHwKaN1/img.png" data-lightbox="lightbox">
        <img src="https://blog.kakaocdn.net/dn/by0qd7/btsC4CH6n47/UsUqv187HBKON8RQHwKaN1/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-origin-width="1646" data-origin-height="886">
    </span>
    
</figure>
<ul data-ke-list-type="disc">
<li>핵사고날의 아키텍처의 핵심은 어댑터와 포트이며, 이두가지 핵심 요소는 독립적으로 역할에 충실하기 위함. 의존성의 방향을 안쪽으로 바라보도록 하도록 해서, 도메인을 지키기 위함이다.</li>
<li>따라서 아키텍처의 목표는 도메인에 집중하고, 덤으로 개발비용이 감소</li>
<li>따라서 아키텍처의 목표는…
<ul data-ke-list-type="disc">
<li>도메인에 집중</li>
<li>(덤으로) 개발비용 감소</li>
</ul>
</li>
</ul>
<ul data-ke-list-type="disc">
<li>마틴파울러의 디자인 스태미너의 가설을 살펴봅시다.</li>
</ul>
<figure data-ke-mobilestyle="widthOrigin" data-origin-width="1264" data-origin-height="788">
    <span data-url="https://blog.kakaocdn.net/dn/bS6f86/btsC38UM7UD/drK86hc9bhK7cO5WInyGS1/img.png" data-lightbox="lightbox">
        <img src="https://blog.kakaocdn.net/dn/bS6f86/btsC38UM7UD/drK86hc9bhK7cO5WInyGS1/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-origin-width="1264" data-origin-height="788">
    </span>
    
</figure>
<blockquote data-ke-style="style1">
<p data-ke-size="size16">관련한 내용은 <b><a href="https://www.youtube.com/watch?v=4E1BHTvhB7Y&amp;t=573s">[마틴 파울러] 소프트웨어 아키텍처의 중요성</a></b> 영상에서 확인할 수 있습니다.</p>
</blockquote>
<ul data-ke-list-type="disc">
<li>해당 그래프는 개발 시간과 고도화를 그래프로 나타낸 것으로 만약 프로젝트를 진행하며 설계나 아키텍처에 신경쓰지 않는다면 파란색의 커브 모양이 되며, 시간이 지날수록 기능이 추가하기 힘들어집니다. 기능을 추가하기 위해 기존 소스 코드를 수정하는데 오래 걸린다.</li>
<li>만약 좋은 설계와 아키텍처를 갖추고 소스코드가 컴포넌트화가 되었다면 어떻게 소스코드를 변경하고 변경하기만 하면 됩니다.</li>
<li>어떻게 소프트웨어의 기능을 변경할지 정하고 변경하면 됩니다. 좋은 아키텍처가 어디를 변경해야 할지 알려주고 가속도가 붙습니다. 왜냐하면 이미 존재한 코드가 플랫폼화 된것이고 플랫폼에서 빠르게 개발하면 된다고, 마틴파울러가 말합니다.</li>
<li>따라서, 좋은 설계와 아키텍처를 갖춘다면 고객에게 좋은 품질 서비스를 빠르게 딜리버리 할수 있습니다.</li>
</ul>
<h2 data-ke-size="size26">감상평</h2>
<ul data-ke-list-type="disc">
<li>맨 처음, 예시로 들어주었던 사진들이 굉장히 쉽게 이해할수 있지 않았나 생각합니다.</li>
<li>결국 프로덕트를 만들어 나가는 사람들의 목표는 <b>쉽고 빠르게 또한 품질이 좋은 기능들을 사용자에게 딜리버리</b>를 하기 위함. 이라고 생각합니다. 그 과정에서 디자이너 / 개발자 / 디자이너 등등 많은 직군분들의 방식이 다른것이라고 생각하고 개발자가 그 목표를 달성하기 위해선 좋은 아키텍처를 고민하고 설계하는 과정이라고 생각합니다.</li>
<li>따라서 개발자로써 아키텍처와 설계를 꾸준히 고민하고 좋다고 생각하는 방향에 대해 시도해나가는것이 가장 중요하다고 생각합니다.</li>
<li>또한, 개발자로써 <b>도메인이 중요해! 그래서 도메인을 어떻게 할것인데?</b> 라는 부분을 고민을 많이 해봐야 할거 같다는 생각이 들었습니다. 여기서도 도메인은 중요하니 보호해야 한다. 라는 말이 나오는데, 어떻게 보호할꺼야? 라는 질문을 끊임없이 찾아가야 하지 않을까 생각합니다.</li>
<li>마지막으로 디자인 스태미너의 가설이라는 것을 처음 들어봤는데 차후 마틴파울러의 강연도 들어봐야 할거 같습니다.</li>
</ul>
            
            
                </div>
            



<ins data-ad-client="ca-pub-9527582522912841" data-ad-slot="3250933968" data-ad-format="auto" data-full-width-responsive="true" data-ad-type="inventory" data-ad-adfit-unit="DAN-VHBugUKpJ1qm98uW"></ins>



                          
            
            </article>
            
            
            
            
              
            
            
            
            
              
              
            
          </div>
      </main>
    </div></div>

Enthusiastically, Steady, Slowly

원본 영상 : https://youtu.be/saxHxoUeeSw?si=Gg1FrAHEgiUKg6U2
세미나 내용
여기서 다룰 내용은 아래와 같습니다
소프트웨어 아키텍처의 목적
클린 아키텍처와 헥사고날 아키텍처
아키텍처의 목표
이 발표를 하는 이유는 개발자들의 용어를 기획자(PM/PO) 분들이 알았으면 좋을거 같고, 기획자의 목표와 개발자의 목표가 같은 곳을 바라보고 있다는 것을 알려주고 싶었다.
소프트웨어는 복잡합니다. 얽히고 얽힌 코드들로 구성되어 있습니다. 따라서 주기적으로 변경이 필요한데요. 위의 사진을 소프트웨어라고 생각한다면 여기서 가위를 칼로 변경해야 한다면 어떻게 해야 할까요? 끈으로 연결되어 있는 다른 도구들의 연결들을 풀고 가위를 칼로 변경하고 다시 연결해줘야 합니다. 이때 갑자기 펜이 다시 가위가 필요해! 라고 한다면, 다시 펜과 가위를 연결하고 이 연결들이 모두 연쇄적으로 영향을 주게 됩니다.
이렇게 되면, 무언가를 변경하고, 추가하려고 하면 굉장히 시간이 오래걸리고 파악하기가 어렵습니다.
다시 위의 사진을 봅시다. 서로 끈으로 연결되어 있지 않고, 포스트잇으로만 모두 연결되어 있는걸 확인할 수 있습니다. 이때 가위를 칼로 변경하려고 할때, 다른 도구들은 신경쓰지 않고 가위를 칼로 변경하면 됩니다. 즉, 변경하기도 쉽고 실제 무언가를 추가하는것도 쉬운거죠. 이걸 클린 아키텍처라고 합니다.
이 과정에서 아키텍처의 목표를 알수가 있는데요. 즉, 소프트웨어를 쉽게 변경할 수 있게 해서 유지보수를 쉽게 하는 것입니다.
그러나 클린 아키텍처라고 보여지는 사진에서 문제가 아직 남아 있긴 합니다. 바로 포스트잇을 변경해야 한다면 어떻게 해야 할까요? 이걸 개발 영역에선 의존성이라고 말하빈다.
조금 간단히 도식화를 해보면 아래 사진과 같습니다.
조금 간단히 도식화 해보면 아래와 같습니다.
여기서 포스트잇이 도메인 / 나머지가 인프라스트럭처입니다.
여기서 도메인이란?
소프트웨어를 이루고자 하는 핵심적인 요소를 말합니다. 예를들어, 해당 발표에선 주문접수 프로세스, 정책 등에 로직이 주문접수 도메인에 포함될것입니다.
그렇다면 인프라스트럭처는?
도메인을 소프트웨어로 제공하기 위한 기능으로 DB, UI, 외부 API 등등을 의미합니다.
지금 그림에서 도메인과 인프라스트럭처는 무수히 많은 선(의존성)이 존재하게 됩니다.
여기서 도메인이란? 소프트웨어로 이루고자 하는 핵심적인 요소를 말한다.
도메인을 소프트웨어로 제공하기 위한 기능
DB, UI, 외부 API 등등
도메인과 인프라스트럭처와 무수히 많은 선, 의존성이 존재한다.
그럼 이제 사용하고 있는 계층형 아키텍처를 보면, 몇가지 문제점이 있게 됩니다.
프리젠테이션 계층이 도메인 계층과 의존되어 있고 도메인 계층은 영속성 계층을 의존하고 있습니다. 즉, 프리젠테이션도 영속성 계층과 의존이 있는거죠. 이렇게 연쇄적인 참조 관계입니다.
의존성이 있다는 것이 변경의 영향을 받는다는 것이고 이렇게 의존성을 가지면 코드를 추가하거나 변경하는게 어려움이 생기게 됩니다. 또한 테스트를 하기도 어렵게 됩니다.
또한, 도메인 계층이 프리젠테이션 계층 / 영속성 계층에 영향을 너무 받게 됩니다. 핵심적인 부분이 다른 영향을 많이 받기 때문에 문제가 생길수도 있습니다. 따라서 도메인 계층을 잘 보호해야 합니다.
따라서 중요한 도메인 계층을 잘 보호해야 합니다.
그렇다면 이제 클린 아키텍처의 헥사고날 아키텍처를 보도록 하겠습니다. 실제 위 사진에 보면, 화살펴고 원 안쪽으로 향하는것을 알수 있습니다. 이것을 하부사항들이 고수준 사항들의 방향으로 단방향으로 의존하는것을 알수가 있습니다. 이런 방향이 되는 이유는 아키텍처가 무엇을 보호하고 집중하는지 보여지기 위함인데, 보면 Entities와 Use case인 도메인을 보호하기 위함입니다.
이걸 다른 도식화로 보면, 도메인 영역이 각 프리젠테이션과 영속성 계층이 안으로 화살표를 바라보게 되는걸 알수 있습니다. 또한 그 부분에서 어댑터(Presenter)가 있는것을 알수 있습니다.
여기서 어댑터란? 전원 어댑터를 생각하면 됩니다. 외부의 데이터 흐름을 내부 데이터로 사용 할 수 있도록 하는, 어댑터만 맞으면 영속성이나 프리젠테이션 영역이 변경되는것에 대해서 문제가 되지 않는 방식입니다. 또한 Repository의 방향은 프리젠테이션과 반대로 되어 있는걸 알수 있는데 이게 바로 의존성 역전이고 인터페이스로 구현이 가능합니다.
어댑터가 도메인을 의존하는 방향이 안쪽을 향하고 있다. 특히 Repository는 방향이 반대로 한다.
이걸 할 수있는 것이 의존성 역전이고, 인터페이스(약속)로 구현가능하다.
이러한 구조 장점
세부사항 변경시 도메인이 영향받지 않습니다.
밖의 세부사항을 손쉽게 변경이 가능하다. 도메인 양측의 약속만 잘 지킨다면 변경이 쉽다.
의존성을 낮추면 각 요소를 독립적으로 테스트가 가능하다.
테스트 데이터가 필요한 경우 인터페이스만 맞춘다면 테스트 데이터로 사용 가능하다.
여기서 가장 중요한것은 세부사항 변경시 도메인이 영향받지 않는다는 점입니다.
핵사고날의 아키텍처의 핵심은 어댑터와 포트이며, 이두가지 핵심 요소는 독립적으로 역할에 충실하기 위함. 의존성의 방향을 안쪽으로 바라보도록 하도록 해서, 도메인을 지키기 위함이다.
따라서 아키텍처의 목표는 도메인에 집중하고, 덤으로 개발비용이 감소
따라서 아키텍처의 목표는…
도메인에 집중
(덤으로) 개발비용 감소
마틴파울러의 디자인 스태미너의 가설을 살펴봅시다.
관련한 내용은 [마틴 파울러] 소프트웨어 아키텍처의 중요성 영상에서 확인할 수 있습니다.
해당 그래프는 개발 시간과 고도화를 그래프로 나타낸 것으로 만약 프로젝트를 진행하며 설계나 아키텍처에 신경쓰지 않는다면 파란색의 커브 모양이 되며, 시간이 지날수록 기능이 추가하기 힘들어집니다. 기능을 추가하기 위해 기존 소스 코드를 수정하는데 오래 걸린다.
만약 좋은 설계와 아키텍처를 갖추고 소스코드가 컴포넌트화가 되었다면 어떻게 소스코드를 변경하고 변경하기만 하면 됩니다.
어떻게 소프트웨어의 기능을 변경할지 정하고 변경하면 됩니다. 좋은 아키텍처가 어디를 변경해야 할지 알려주고 가속도가 붙습니다. 왜냐하면 이미 존재한 코드가 플랫폼화 된것이고 플랫폼에서 빠르게 개발하면 된다고, 마틴파울러가 말합니다.
따라서, 좋은 설계와 아키텍처를 갖춘다면 고객에게 좋은 품질 서비스를 빠르게 딜리버리 할수 있습니다.
감상평
맨 처음, 예시로 들어주었던 사진들이 굉장히 쉽게 이해할수 있지 않았나 생각합니다.
결국 프로덕트를 만들어 나가는 사람들의 목표는 쉽고 빠르게 또한 품질이 좋은 기능들을 사용자에게 딜리버리를 하기 위함. 이라고 생각합니다. 그 과정에서 디자이너 / 개발자 / 디자이너 등등 많은 직군분들의 방식이 다른것이라고 생각하고 개발자가 그 목표를 달성하기 위해선 좋은 아키텍처를 고민하고 설계하는 과정이라고 생각합니다.
따라서 개발자로써 아키텍처와 설계를 꾸준히 고민하고 좋다고 생각하는 방향에 대해 시도해나가는것이 가장 중요하다고 생각합니다.
또한, 개발자로써 도메인이 중요해! 그래서 도메인을 어떻게 할것인데? 라는 부분을 고민을 많이 해봐야 할거 같다는 생각이 들었습니다. 여기서도 도메인은 중요하니 보호해야 한다. 라는 말이 나오는데, 어떻게 보호할꺼야? 라는 질문을 끊임없이 찾아가야 하지 않을까 생각합니다.
마지막으로 디자인 스태미너의 가설이라는 것을 처음 들어봤는데 차후 마틴파울러의 강연도 들어봐야 할거 같습니다.

[우아콘 2022] 기획자님들! 개발자가 아키텍처에 집착하는 이유 쉽게 알려드립니다.

댓글