다시 본업.
자바코드로 구현하는 클린 웹 애플리케이션.
hexagonal architecture를 제시하고 이를 구현하기 위한 소스제공.
그리고 소스단위로 설명하면서 몇 가지 상황에 따른 전략제공.
그리고 spring jpa 조합에서의 설명 제공.
https://alistair.cockburn.us/hexagonal-architecture/
Hexagonal architecture
Create your application to work without either a UI or a database so you can run automated regression-tests against the application, work when the database becomes unavailable, and link applications together without any user involvement. Japanese translati
alistair.cockburn.us
입사해서 3년정도 고민이 많았었다.
그당시 나의 두목이 만들었던 heo framework.
스프링이 없이 약간 스트러츠 변형 같기도 하고 혼자 독학으로 아키텍처를 구성하셨는데,
viewbean(dto)
controller
service interface
service implement
dao interface
dao implement
modelbean(model)
물론 dao는 ibatis를 사용.
대충 이런 구조였었는데,
대학에서야 워낙 웹쪽을 배운 적도 거의 없고,
2000년 초반이었으니 교수들은 웹을 개무시했던거 같고,
그나마 jsp로 페이지내에 db connection까지 있는 것 프로젝트로 몇 번 해봤었다. 그것도 누가 알려줘서 그런것은 아니고 프로젝트에 웹이 필요한 경우가 가끔 있었기 때문에.
어쨋든 struts와 spring 2.x의 어딘가 있었고,
(struts 또한 제대로 본적은 없는데 대충 짐작이고, 언젠가 cns의 struts 베이스의 프레임워크로 잠깐 프로젝트 하면서 쌍욕한적이 있었다.)
가장 화가나는 포인트는
화면에 컬럼 하나 바뀌면 저 모든 로직을 빠짐없이 바꾸어야 하는 부분이었다.
저렇게 괜찮은 구조인데 왜 화면 하나 바꾸는데 모든 것을 바꾸어야하는지 지금도 잘 이해는 안된다.
(디테일 소스가 기억이 안나니까 ㅋㅋ)
나의 두목은 MVC와 객체지향의 찬양자였는데,
정작 본인이 만든 프레임워크가 수정에 얼마나 치명적인지 이해하려는 마음도 없었다.
만드는건 본인이 거의 주도하고 유지보수는 내가 도맡아서 했으니...
7년 정도 함께 하면서 나중에는 거의 인간관계도 틀어질 정도로 멀어졌었는데,
지금 생각하면 내 개발인생에서 손에 꼽을 정도로 고마운 사람이긴 하다.
어쨋든 퇴사 후 2015년 springboot로 모든 것을 리셋하면서 나의 생산성은 극화된다.
이때 아쉬운 부분은 JPA를 하려고 했으나 여러가지 핑계로 하지 않았던 부분.
어쨋든 대부분이 소규모였기에 가장 치명적으로 잘했던 부분은
"매핑하지 않기 전략" 이었다.
8장에 경계 간 매핑하기에서 언급된 부분이고,
11장에서 지름기를 우려하면서 다시 또 나오는 도메인 엔티티를 입출력 모델로 사용하기 부분이다.
위 구조는 모두가 하지 말라는 부분이지만,
하나 바꾸면 모든 것을 바꾸는 것에 지쳐있던 터라 저 방식을 사용했고,
심지어 mybatis에서 java reflection을 사용해서 기본 객체로부터 insert , update를 자동으로 되게 하는 것도 구현해서 가지고 다녔다.
(spring data jpa의 save랄까 ㅋㅋ. 당연히 구조는 그렇게 아름답지 않지만)
그래서 화면에서 필요해지는 것이 있으면 model 객체 하나 수정하고 화면 수정해서 자동화시키는 강결합을 꽤나 오래 써왔다.
소규모에서 극강의 생산력과 유지보수력이었다.
(당시 나의 많은 프로젝트는 오픈 후 망하거나 별로 안썼어서 치명적으로 좋았다.)
이것은 2019년쯔음 깨지게 된다.
나와 비슷한 사상을 가진 분이 우리 프로젝트에서 JPA를 사용하여 창의적으로 개발하여 큰 손실을 입히면서 깨달음을 얻었다.
도메인 엔티티 모델을 입출력으로 사용한 정도에 그치지 않고, 당시 나의 표현을 다시 하자면
서울 <-> 부산간에 화물을 주고 받는데,
서울에서 출발하여 화성에서 추가 물건을 올리거나 내려야하는데 부산까지 가야지만 올릴 수 있는 구조
(화성은 커녕 서울로 돌아만 가도 어떻게 하겠는데 무조건 부산까지 가야지 할 수 있게 해둠 거의 goto 사용한 느낌)
밥형도 마침 나와 비슷한 메타포를 사용해서 표현했다.
잠시 또 다른 얘기를 하자면 인사이트의 Clean Architecture에서 90페이지에 ISP:인터페이스 분리 원칙에서는
"불필요한 짐을 실은 무언가에 의존하면 예상치도 못한 문제에 빠진다" 로 되어 있는데 번역이 살짝 아쉽다.
어쨋든 규모도 커져가고 내가 꽤나 믿었던 분의 일탈?로 인해서
당시에 다시금 아키텍처와 프레임워크에 대해서 고민하게 됐었다.
그로부터 시간이 꽤 흘렀고, 최근 외도를 하다가 다시 본업에 집중하면서 아키텍처를 고민하게 된다.
현재 우리의 아키텍처가 꽤나 훌륭하다고 생각하고 유지보수할때 예전과 같은 아쉬움도 없지만,
여기서 더 나아지기 위해서 결단을 내려야할 때.
3m에서 이 구조들을 유즈케이스 스터디부터 단단히 하여 한번 더 도약해야겠다.
(근데 두 마리 토끼를...거의 동시에... 언어도 코틀린으로 바꿔야한다.)
'서재' 카테고리의 다른 글
| Clean Agile (0) | 2023.06.04 |
|---|---|
| 잠들어 있는 성공시스템을 깨워라 (0) | 2023.05.17 |
| 연금술사 (0) | 2023.05.01 |
| 클린 아키텍처 (5.결론) (0) | 2023.04.29 |
| 클린 아키텍처 (4.내가 궁금했던 점) (0) | 2023.04.29 |