다시 [디자인 주도 개발]을 읽고 있습니다. (줄여서 DDD)

저자가 자신이 DDD를 추진하면서 겪어던 일련의 과정을 클래스다이어그램으로 설명하고 있어요. 

그런데 내가 여기서 DDD를 떠나서 국내의 IT환경의 특수성을 말해보고 싶은게요. 
비즈니스로직이 데이타베이스의 스토어드프로시저로 작성된 경우가 많다는겁니다. 
아마도 그 옛날 Host-Terminal 시대의 그 서버로직이 그대로 DB사이드의 StoredProcedure로 이전되면서 그대로 굳어버린것 같아요. 

이지점이 문제인데요. 국내환경은 디자인패턴을 적용할수가 없어요. 기껏해야 재활용가능한 단위로 Function 또는 StoredProcedudre로 작게 나누는것 정도예요. 그런데 이 DB에 비즈니스로직을 두는데 설계자들에게는 전폭적인 지지를 받더군요. SQL정도는 할 수 있기 때문에 로직이 틀렸을때 본인인 직접 수정할 수 있기 때문이죠. 

어떤 설계자는 비즈리스로직을 DB에 두지 않았더라면 프로젝트를 성공시킬수 없을것이라고 평가하더라구요. 나의 평가는 정반대입니다. DB에 비즈니스로직을 두었기 때문에 프로젝트가 어려워진거라는거죠. 시간이 갈수록 스토어드프로시저에
SM(운영자)등이 관련 로직을 추가합니다. 대부분 if~else로 긴급한 상황을 넘기죠. 그러곤 그뿐이예요. 사람이 교체되고 그 히스토리를 모르는채로 계속 로직은 증가합니다. 이후 리뉴얼 프로젝트에도 이 스토어드프로시저는 살아남습니다. 왜냐하면 복잡한 로직이긴 한데 왜 그렇게 했는지는 판단이 잘 않되고 고객들은 이미 이상황에 잘 적응해서 불만이 없거든요. 

이렇게되다 보니 스토어드프로시저는 암세포처럼 계속 커져만 갑니다. 
스마트폰 열풍이 위피로 대표되는 국내의 휴대폰개발환경을 혁신했듯이 SI업계의 이 기형적인 불합리도 외부의 충격으로 극복되리라 봅니다. 클라우드가 계기가 될까요? 개발자본인들도 의식적으로 적극적인 주장을 할 일입니다.

http://www.facebook.com/happycode