다시 [디자인 주도 개발]을 읽고 있습니다. (줄여서 DDD)
저자가 자신이 DDD를 추진하면서 겪어던 일련의 과정을 클래스다이어그램으로 설명하고 있어요.
그런데 내가 여기서 DDD를 떠나서 국내의 IT환경의 특수성을 말해보고 싶은게요.
비즈니스로직이 데이타베이스의 스토어드프로시저로 작성된 경우가 많다는겁니다.
아마도 그 옛날 Host-Terminal 시대의 그 서버로직이 그대로 DB사이드의 StoredProcedure로 이전되면서 그대로 굳어버린것 같아요.
이지점이 문제인데요. 국내환경은 디자인패턴을 적용할수가 없어요. 기껏해야 재활용가능한 단위로 Function 또는 StoredProcedudre로 작게 나누는것 정도예요. 그런데 이 DB에 비즈니스로직을 두는데 설계자들에게는 전폭적인 지지를 받더군요. SQL정도는 할 수 있기 때문에 로직이 틀렸을때 본인인 직접 수정할 수 있기 때문이죠.
어떤 설계자는 비즈리스로직을 DB에 두지 않았더라면 프로젝트를 성공시킬수 없을것이라고 평가하더라구요. 나의 평가는 정반대입니다. DB에 비즈니스로직을 두었기 때문에 프로젝트가 어려워진거라는거죠. 시간이 갈수록 스토어드프로시저에
SM(운영자)등이 관련 로직을 추가합니다. 대부분 if~else로 긴급한 상황을 넘기죠. 그러곤 그뿐이예요. 사람이 교체되고 그 히스토리를 모르는채로 계속 로직은 증가합니다. 이후 리뉴얼 프로젝트에도 이 스토어드프로시저는 살아남습니다. 왜냐하면 복잡한 로직이긴 한데 왜 그렇게 했는지는 판단이 잘 않되고 고객들은 이미 이상황에 잘 적응해서 불만이 없거든요.
이렇게되다 보니 스토어드프로시저는 암세포처럼 계속 커져만 갑니다.
스마트폰 열풍이 위피로 대표되는 국내의 휴대폰개발환경을 혁신했듯이 SI업계의 이 기형적인 불합리도 외부의 충격으로 극복되리라 봅니다. 클라우드가 계기가 될까요? 개발자본인들도 의식적으로 적극적인 주장을 할 일입니다.
http://www.facebook.com/happycode
올라온지가 쫌 된 글인데 아무도 답을 안하다니..
이런 이런..
일단, 너무 한쪽 면만 보신 것 같습니다.
리팩이나 패턴(GoF하고, 다른거 하나 더 있습니다. 갑자기 기억이..ㅠ.ㅠ. 번역본이 없었던 걸로 아는데...)
OOD나 SOA도 좀 보시고, DB의 Stored Procedure나 Function, Trigger도 좀 더 깊이있게 이해하셔야 할 것 같습니다.
또한 운영체제와 System Programming도 좀 더 공부하셔야겠네요..
(글쓰신 내용을 보건데, 냉정히 말해 언어론도 보시는게 좋을듯합니다.)
모든 Logic이 Stored Procedure나 Function, Trigger 에 녹아있어도 문제지만,
그것들을 완전히 들어내는 것도 좋은 방법이 아닙니다.
c언어가 그렇게 오래되었고, c++이 더 나은거라고 그렇게 외쳐대도, Java가 좋다고 그렇게 외쳐도
객체지향이 시장을 지배하지 못하는 이유도 생각해보셔야 할 것 같습니다..