답변:
가능한 한 아키텍처 결정을 지연시키는 원칙을 준수하려고 할 수 있습니다. 미래에 지금보다 문제 영역에 대해 더 많이 알게 될 것이라는 생각이 들기 때문에 오늘날 내리는 모든 결정은 의심의 여지가 있습니다.
이것을 결합하는 또 다른 좋은 원칙은 요구 사항의 가장 위험한 부분을 먼저 시도하는 것입니다. 쉬운 부분을 수행하면 위험한 부분이 다른 방향으로 움직인다는 생각이 있습니다. 쉬운 부품을 다시 사용하십시오. 여기서 위험한 것은 당신이 어떻게해야하는지 잘 모르는 것을 의미합니다.
이 두 가지를 고려할 때 종종 OO 관점에서 사물에 접근하려고 시도하면 먼저 응용 프로그램의 가장 위험한 부분에 대한 OO 모델로 시작하고 가장 만족할만한 코드를 구현할 수 있습니다. 위험한 요구 사항. 그런 다음 필요한 기능을 추가하기 위해 필요에 따라 OO 모델 확장을 시작하십시오. 그 동안 SQL 또는 NoSQL 또는 플랫 파일 또는 클라우드 스토리지를 사용할지 여부에 대한 결정을 완전히 지연시킬 수 있으며 결국 관계를 원하지 않을 수도 있습니다 (ER 모델이 필요 없음).
ER 모델은 애플리케이션의 데이터가 유지되는 방식을 나타내며, OO 모델은 동일한 데이터가 메모리에 저장되는 방식 또는 애플리케이션이 실행되는 동안 결정합니다. 따라서 데이터베이스 스키마 디자인 (ER 모델)과 클래스 구조 디자인 (OO 모델)은 관련 디자인 고려 사항이며 일반적으로 동시에 생각할 수도 있습니다. 실제로, ORM (Object-Relational Mapping) 도구를 사용하는 경우 ER 모델과 OO 모델이 하나 일 수 있습니다. 다시 말해, 클래스 (OO 모델)는 자체적으로 ER 모델을 지정하는 방식으로 주석이 달릴 수 있습니다.
그러나 디자인하기 전에 소프트웨어의 실제 요구 사항, 사용 대상, 사용 방법 및 사용 대상에 대해 잘 알고 있어야합니다. 많은 개발자들이 제품이 해결해야 할 필요성을 완전히 이해하기 전에 설계 결정에 대해 생각하기 시작하고 응용 프로그램의 실제 목적에 적합하지 않은 설계로 끝납니다.