이 글은 2017년 9월 27일 15:32에 Summer가 마지막으로 편집했습니다.
이 글은 Q&A를 모방한 짧은 소설이며, 저자는 유머러스한 스타일로 건축가들이 하는 일을 간략히 분석합니다: 저는 소프트웨어 아키텍트가 되고 싶습니다. 이것은 젊은 소프트웨어 개발자들에게 훌륭한 선택입니다. 저는 팀을 이끌고 데이터베이스와 프레임워크, 웹서버 등에 관한 중요한 결정을 내리고 싶습니다. 아, 그럼 소프트웨어 아키텍트가 되고 싶지 않은 거군요. 물론 중요한 결정을 내리는 사람이 되고 싶었죠. 그건 괜찮지만, 중요한 결정들은 목록에 포함하지 않아요. 그건 관련 없는 결정들이니까요. 무슨 뜻인가요? 데이터베이스가 중요한 결정이 아니라는 말인가요? 우리가 얼마나 많은 돈을 쓰는지 아시나요? 아마 너무 비싼 걸 수도 있어. 하지만 데이터베이스는 중요한 결정 중 하나가 아닙니다. 어떻게 그렇게 말할 수 있니? 데이터베이스는 시스템의 핵심으로, 모든 데이터가 체계화되고 분류되며 색인화되고 접근됩니다. 데이터베이스가 없으면 시스템도 존재하지 않을 것입니다. 데이터베이스는 분류, 쿼리, 정보 보고를 위한 유용한 도구를 제공하는 IO 장치일 뿐, 이는 시스템 아키텍처의 보조 기능에 불과합니다. 도움이 필요해? 이건 말도 안 돼. 맞아요, 보조 기능이에요. 시스템의 비즈니스 규칙은 이러한 도구 중 일부를 활용할 수 있지만, 해당 도구들은 해당 비즈니스 규칙에 내재된 것은 아닙니다. 필요하다면 기존 기구를 다른 도구로 교체할 수도 있습니다; 그리고 비즈니스 규칙은 변하지 않을 것입니다. 네, 맞아요. 하지만 이 도구들은 원래 데이터베이스에서 사용되었기 때문에 다시 코딩해야 했습니다. 그게 네 문제야. 무슨 뜻인가요? 당신의 문제는 비즈니스 규칙이 데이터베이스 도구에 의존한다고 생각하지만, 실제로는 그렇지 않다는 점입니다. 적어도 좋은 아키텍처가 제공되기 전까지는 이런 상태가 되어서는 안 됩니다. 정말 미친 짓이에요. 그런 도구를 사용하지 않는 비즈니스 규칙은 어떻게 만들 수 있나요? 데이터베이스 도구를 사용하지 않는다는 말은 아니지만, 의존하지 않습니다. 비즈니스 규칙은 어떤 데이터베이스를 사용하는지 알 필요가 없습니다. 그렇다면 어떤 도구를 사용해야 할지 모르는 상태에서 어떻게 비즈니스 규칙을 얻을 수 있을까요? 의존성을 역전시켜 데이터베이스가 비즈니스 규칙에 의존하도록 하세요. 비즈니스 규칙이 데이터베이스에 의존하지 않도록 하세요. 말도 안 되는 소리 하지 마. 오히려 저는 소프트웨어 아키텍처의 언어를 사용하고 있습니다. 이것이 의존성 역전 원리입니다: 저수준 표준은 고수준 표준에 의존해야 합니다. 말도 안 돼! 상위 수준 기준(비즈니스 규칙을 참조한다고 가정) 저수준 기준 호출(데이터베이스를 참조한다고 가정). 따라서 고수준 기준은 호출자가 호출자에게 의존한다는 원칙에 따라 낮은 수준 기준에 의존하게 됩니다. 모두가 알고 있죠! 이것은 실행 시간에도 해당됩니다. 하지만 컴파일 시 우리가 원하는 것은 의존성 역전입니다. 상위 가이드라인의 소스 코드는 저수준 가이드라인의 소스 코드를 언급해서는 안 됩니다. 서둘러! 말도 안 하고 어떻게 전화를 할 수 있죠? 물론이죠. 그것이 바로 객체지향이 관련된 것입니다. 객체 지향은 실제 모델의 생성에 관한 것으로, 데이터, 기능, 그리고 일관된 객체를 결합하는 것입니다. 코드를 직관적인 구조로 조직하는 것입니다. 그게 다들 말하는 거야? 우리 모두 알다시피, 이것은 명백한 진실입니다. 네, 그렇습니다. 하지만 객체지향 지침을 사용할 때는 언급하지 않고도 호출이 가능합니다. 그럼 어떻게 하죠? 객체지향 설계에서는 객체들이 서로 메시지를 전송합니다. 맞아요, 물론이죠. 송신자가 메시지를 보낼 때, 수신자의 유형을 알지 못합니다. 사용된 언어에 따라 다릅니다. 자바에서는 송신자가 최소한 수신기의 기본 타입을 알고 있습니다. 루비에서는 송신자가 적어도 수신자가 받은 메시지를 처리할 수 있다는 것을 알고 있습니다. 맞아요. 어쨌든 발신자는 수신기 종류를 알지 못합니다. 맞아, 그렇지. 따라서 송신자는 특정 수신기 유형을 언급하지 않고도 기능을 수행할 수신기를 설계할 수 있습니다. 맞아, 맞아. 이해합니다. 하지만 발신자는 여전히 수신자에게 의존합니다. 이것은 실행 시간에도 해당됩니다. 하지만 컴파일되면 다릅니다. 송신자의 소스 코드는 수신자의 소스 코드를 언급하거나 의존하지 않습니다. 사실, 수신자의 소스 코드는 송신자의 소스 코드에 의존합니다. 안 돼요! 발신자는 여전히 보낸 클래스에 따라 다릅니다. 아마도 소스 코드를 통해 더 명확해질 것입니다. 다음 단락은 자바어로 작성되었습니다. 먼저 발신자입니다: 소포 발신자; 공용 클래스 송신자 { 사설 수령 수령인; 공개 송신자(수신자 r) { 수신자 = r; } 공공 공무 doSomething () { 수신자.receiveThis (); } 공용 인터페이스 수신자 { void receiveThis (); } }수신자는 여기 있습니다: 패키지 수신기; 수입 발신자. 발신자; public 클래스 SpecificReceiver는 Sender.Receiver를 구현합니다 { public void receiveThis () { //do something 흥미로운 것. } }참고: 수신자는 발신자에 따라 다르고, SpecificReceiver는 발신자에 의존하며, 송신자에는 수신기 관련 정보가 없습니다. 네, 하지만 거짓말이에요. 수신자의 인터페이스를 송신자 클래스에 넣었잖아요. 이제 이해하기 시작했어. 뭘 알고 있어? 물론, 그것은 건축의 원칙입니다. 송신자는 수신자가 구현해야 하는 인터페이스를 가지고 있습니다. 만약 중첩된 클래스를 사용해야 한다면 그...... 중첩된 클래스는 목적을 위한 수단 중 하나일 뿐이며, 다른 방법들도 있습니다. 잠깐만. 이것이 데이터베이스와 무슨 관련이 있나요? 우리는 데이터베이스에 대해 이야기하기 시작했습니다. 코드를 좀 더 살펴보겠습니다. 첫 번째는 간단한 비즈니스 규칙입니다: 패키지 비즈니스규칙; 수입 엔터티. 뭔가; 공용 클래스 BusinessRule { private BusinessRuleGateway gateway; public BusinessRule (BusinessRuleGateway gateway) { this.gateway = gateway; } public void execute (String id) { gateway.startTransaction (); Something thing = gateway.getSomething (id); thing.makeChanges (); gateway.saveSomething (사물); gateway.endTransaction (); } }비즈니스 규칙은 큰 영향력을 갖지 못합니다. 이것은 단지 한 가지 예일 뿐입니다. 다양한 비즈니스 규칙을 구현하는 클래스가 더 많을 수도 있습니다. 자, 게이트웨이가 정확히 뭐야? 비즈니스 규칙을 통해 모든 데이터 접근 방식을 제공합니다. 다음과 같이 구현하세요: 패키지 비즈니스규칙; 수입 엔터티. 뭔가; public interface BusinessRuleGateway { Something getSomething (String id); void startTransaction (); 공허 세이브(무언가); 무효 종료트랜잭션 (); }참고: 이 내용은 businessRules에 있습니다. 좋아, 무언가 클래스가 뭐야? 간단한 비즈니스 객체를 나타냅니다. 저는 그것을 엔티티(entities)로 표현했습니다. 패키지 엔터티; public class something { public void makeChanges () { //... } }궁극적으로 BusinessRuleGateway 구현에서 이 클래스는 실제 데이터베이스를 알고 있습니다: 패키지 데이터베이스; import, businessRules.BusinessRuleGateway; 수입 엔터티. 뭔가; public class MySqlBusinessRuleGateway는 BusinessRuleGateway { public Something getSomething (문자열 ID) { // MySQL을 사용해 thing을 얻습니다. } public void startTransaction () { // start MySql transaction } public void saveSomething (Something thing) { // MySql에서 save thing) } public void endTransaction () { // end MySql 트랜잭션 } }또한, 비즈니스 규칙은 런타임에 데이터베이스를 호출한다는 점에 유의하세요; 하지만 컴파일 시에는 데이터베이스가 businessRules에 의존하고 있습니다. 음, 이제 이해가 된 것 같아. 다형성을 사용해 데이터베이스가 비즈니스 규칙에서 구현되었다는 사실을 숨기고 있을 뿐입니다. 하지만 비즈니스 규칙에 모든 데이터베이스 도구를 제공하기 위해서는 여전히 인터페이스가 필요합니다. 아니, 전혀 아니야. 우리는 비즈니스 규칙에 맞춘 데이터베이스 도구를 제공하려 하지 않았습니다. 대신 필요한 인터페이스를 만들기 위해 비즈니스 규칙을 사용합니다. 이 인터페이스를 구현하면 적절한 도구를 호출할 수 있습니다. 네, 하지만 모든 비즈니스 규칙에 대해 모든 도구를 사용해야 한다면 그 도구를 게이트웨이 인터페이스에 넣으면 됩니다. 아직도 이해하지 못하는 것 같아. 뭘 이해한다는 거야? 이 점은 이미 명확합니다. 각 비즈니스 규칙은 필요한 데이터 접근 도구에 대한 하나의 인터페이스만 정의합니다. 잠깐만, 어떻게 할래? 이것이 바로 인터페이스 분리 원칙입니다. 각 비즈니스 규칙 클래스는 데이터베이스의 특정 기능만을 사용합니다. 따라서 각 비즈니스 규칙이 제공하는 인터페이스는 해당 시설에만 접근할 수 있습니다. 하지만 이는 다양한 인터페이스와 다른 데이터베이스 클래스를 호출하는 작은 구현 클래스가 존재함을 의미합니다. 좋아, 이제 이해하기 시작했구나. 하지만 너무 복잡하고 시간 낭비입니다. 왜 이런 짓을 하는 걸까요? 이렇게 하면 체계적이고 시간을 절약할 수 있습니다. 자, 코드 자체를 위해 코드를 많이 만들어 보세요. 반대로, 중요한 아키텍처 결정으로 인해 무관한 결정이 지연될 수 있습니다. 그게 무슨 뜻인가요? 처음에 소프트웨어 아키텍트가 되고 싶다고 했던 게 기억나요? 정말 중요한 모든 결정을 내리고 싶어 합니다. 네, 저도 그렇게 생각했어요. 데이터베이스, 웹서버, 프레임워크에 대해 의사결정을 내리고 싶지 않나요? 네, 당신은 그런 게 중요하지 않다고 말하죠. 그냥 관련 없는 내용일 뿐이에요. 맞아요. 그거에요. 소프트웨어 아키텍트가 내리는 중요한 결정은 데이터베이스, 웹서버, 프레임워크에 관한 결정을 가능하게 하는 것입니다. 하지만 어떤 것부터 먼저 결정해야 해요! 아니, 안 돼. 사실, 이런 결정은 개발 과정 후반, 정보가 더 풍부해질 때 결정할 수 있습니다. 아키텍트가 사전에 프레임워크를 정했는데 필요한 성능을 제공하지 못하거나 견딜 수 없는 제약을 도입하는 경우는 재앙입니다. 건축가가 결정을 연기하기로 결정할 때에만 정보가 충분했을 때 결정을 내립니다; 느리고 자원이 많이 드는 IO 장치와 프레임워크를 사용하지 않는 팀은 아키텍트의 재량에 따라 빠르고 가벼운 테스트 환경을 만들 수 있습니다. 오직 그 설계자들만이 진정으로 중요한 것에 신경 쓰고, 그렇지 않은 것은 지연시키며, 그런 팀이 운이 좋은 팀이다. 말도 안 돼요, 무슨 말씀인지 전혀 이해가 안 돼요. 이 글을 잘 살펴보세요. 그렇지 않으면 또 10년을 기다려야 할 겁니다.
| 
게시됨 2017. 9. 27. 오후 3:29:46
|
|
|
게시됨 2017. 9. 28. 오후 3:00:37
|
집주인|
게시됨 2017. 9. 29. 오전 8:34:23
|
게시됨 2018. 11. 27. 오전 11:12:17
|
