본문 바로가기

전체 글196

너무 많은 이해관계자들을 위한, 너무 많은 시스템을 위한 아키텍처 여기에 아주 근사한 아키텍처를 기반으로 만든 시스템이 있다. 이 아키텍처는 SoC(Separation of Concerns)의 원칙에 따라서 내부 시스템 간에 느슨한 결합(loosely coupled)을 통해 서로 연결되고, 각 계층(layer)은 의존관계(dependency)의 원칙하에 내부 모듈은 호출하게 되어 있다. 다소 어쩔 수 없는 솔루션이나 외부 시스템 때문에 일부 아키텍처가 균형을 이루지 못한 부분도 있지만, 극히 일부분이고, 그리 많이 사용하지 않은 기능이라 이 부분 역시 중요한 모듈과는 최대한 의존관계를 줄이도록 설계를 했다. 기능적으로도 품질적으로도 사용자가 만족할 만한 수준의 아키텍처가 만들어졌으며, 충분히 문서화 작업도 이루어져 있다. 이제 이 시스템이 운영 단계에 접어들면서 운영에.. 2012. 2. 28.
비즈니스 관점의 프로세스와 IT 관점의 프로세스 분석 설계를 진행하다 보면 프로세스라는 단어가 많이 등장하고, 이는 어떤 관점에서 이를 바라보는가에 따라서 그 의미와 해석의 차이를 느끼게 된다. IT에 대한 지식이 전혀 없는 사람이 프로세스라는 단어를 언급하는 것을 보면 시스템에서 제공하는 기능과 사람이 처리하는 기능이 한데 섞여져 있어서 마치 사람의 행위를 시스템이 처리하는 것과 같은 인상을 받을 때도 있다. 반면에 IT를 수행하는 사람의 관점에서 프로세스라는 단어를 들을 때에는 사용자의 행위와 화면과의 연계, 내부 모듈 및 시스템 간의 연계되는 관계를 상세하게 생각하여 오프라인에서 수행되는 프로세스를 마치 시스템 내부에서 진행하는 형태로 착각하기도 한다. 모든 프로세스가 시스템화되는 것이 가장 바람직하다고도 볼 수 없으며, 시스템화되지 못한 프로세.. 2012. 1. 29.
데이터 양과 비즈니스 로직의 복잡도 흔히들 데이터 양이 많으면 비즈니스 로직이 복잡해진다고 생각할 수 있다. 하지만, 데이터의 양과 비즈니스 로직의 복잡도는 그리 관계가 없다. 오히려 데이터 내의 개념들의 양과 더 깊은 관계가 있다. 가장 단순하게 게시판 글을 생각해봐도 그 내용이 한없이 길어도 단순히 내용만을 보여준다면 비즈니스 로직은 그리 복잡할 것은 없다. 하지만, 그 게시판의 글의 내용에 대한 의미들을 분석해서 나름대로 체계적으로 보여준다면 이는 이를 어떻게 보여주어야 하는 개념들만큼 복잡도가 증가하며 그 개념들 간의 관계까지 고려한다면 기하급수적인 비즈니스 로직이 생겨날 수 밖에 없다. TodaysArt 2008 - 16n _ ƒ5³ by Haags Uitburo 게시글을 서론, 본론, 결론의 형태로 묶음 단위를 생각해서 화면에 .. 2012. 1. 19.
설계, 누구를 위한 활동인가 작업을 수행하는 사람들은 늘 흔적을 남기기 마련이며, 이를 SW에서는 산출물이라고 말한다. 즉, 어떠한 활동을 하든지 간에 그 흔적이 어떠한 형태로든 존재하기 마련인 것이다. SW 개발하는 입장에서 설계와 구현의 정확한 구분을 한다는 것은 사실 거의 불가능한 영역이기도 하다. 설계를 개발 단계 중에 정해진 기간으로 놓고 그 단계 내에서 산출물을 강요하는 식의 방식은 설계의 본연의 목적을 잃을 가능성이 너무나도 높다. Anonymity; and the Internet. by Stian Eikeland 우리는 어떤 일을 하게 될때 머리속으로 먼저 무엇을 어떻게 수행할지를 가늠해본다. 좀더 깊이 생각하는 사람은 다양한 대안들을 생각해보고 각각의 장단점을 비교하여 사전 시뮬레이션까지도 고려하여 최적의 해결책이라.. 2011. 12. 22.
반응형