내 소프트웨어 디자인을 아키텍처 패턴과 매핑하는 데 혼란을 겪고 있습니다.이것은 계층화 된 아키텍처입니까?
아래 다이어그램은 나의 제안을 설명합니다. 내가 물어보고 싶은게 무엇 
입니다 -
레이어는 정확한 용어가 아니며 필요에 따라 맞춤 설정할 수 있습니다. 내가 당신의 디자인을 다른 비트를 구성 할 것이라고 말했다 :
세 번째 계층은 실제로 메인 소프트웨어 흐름에 서비스를 제공하지만, 그들에 적극적인 역할을하지 않는 쪽 층/패키지입니다. 필요에 따라 필요한 서비스와 상호 작용할 수있는 2 개의 첫 번째 레이어와 함께 배치하는 것이 더 적절할 것입니다.
네 번째 레이어는 실제로 시스템 외부의 엔티티에 대한 설명이기 때문에 디자인의 일부가 아니어야합니다. 이 엔티티에 대한 인터페이스를 개략적으로 설명 할 수 있지만 시스템에서 레이어를 구성하지는 않습니다.
또한 묘사 설계를위한 형식적인 접근 방법을 살펴 수 있습니다 - (표준하지만 당신이 어떻게 보이는지에 가까운되지 않음) UML에서 Package diagrams 및 Layer diagrams을 확인합니다.
여기에서 문제는 세 번째 레이어 (도구 및 서비스)는 GUI가 아닌 두 번째 레이어 (Command API)에서만 사용된다는 것입니다. GUI에서 서비스 및 도구의 세부 사항을 숨기기 위해 두 번째 계층을 도입했습니다. 필자의 디자인은 TCP/IP 프로토콜 스위트 에서처럼 위에서 아래로의 통신 흐름을 엄격하게 따릅니다. 또한 모든 기능이 결국이 서비스/도구 계층에서 수행되기 때문에 세 번째 계층을 측면 구성 요소로 처리 할 수 없으며 모든 작업에 allways가 필요합니다. 당신은 내가 생각하는 네 번째 계층이 맞습니다. 그것에 대한 의문으로 분명 해져야합니다. – khoks
도구와 서비스가 실제로 두 번째 계층에만있는 경우 실제로 두 번째 계층의 일부로 포함하는 것이 좋습니다. 올바른 범위를 유지하는 것이 중요합니다. – SomeWittyUsername
나는 또한 그렇게 생각했습니다. 그러나 모든 계층은 계층화 된 아키텍처 패턴에 따라 상위 계층을 의미합니다. 심지어 두 번째 레이어는 GUI 레이어에서만 사용됩니다. 처음에는 두 번째 레이어와 세 번째 레이어를 하나의 레이어로 그룹화했지만 툴과 서비스에는 테마/인터페이스가 통합되지 않았기 때문에 그러나 TCP/IP 프로토콜 스위트에서도 서로 독립적 인 각 계층에서 선택할 수있는 여러 프로토콜이 있습니다. 또한 API의 경우 앱 프로그래밍 인터페이스 레이어는 자주 사용되는 기능의 하위 레이어를 캡슐화합니다. – khoks
이미지가 너무 작아서 전혀 만들 수 없습니다. – Koterpillar
글쎄, 나는 지금 http://s20.postimg.org/gjuxkg0al/for_stack_overflow.png 링크를 클릭했다. 그 해상도는 꽤 크다. 브라우저가 축소 된 이미지를 표시하지 않는 것이 틀림 없는가? – khoks
이제 괜찮아 보이고 다시 업로드되었을 수 있습니다. – Koterpillar