민첩한 아키텍처 [닫기]

https://stackoverflow.com/questions/19235

09-06-2019
|

문제

대학원 논문을 시작하고 있는데 주제는 "애자일 아키텍처"입니다.

기본적으로 전통적인 소프트웨어 개발 방법론에 대한 설명과 그에 따른 애자일 방법론의 탄생으로 시작하여 소프트웨어 구성의 고유한 변화에 쉽게 적응할 수 있는 유연한 애플리케이션 아키텍처의 권장 사항과 설계로 마무리됩니다.

제 질문은 이러한 아키텍처에 어떤 패턴과 디자인 방식을 권장하시겠습니까?입니다.저는 종속성 주입, 높은 유지 관리 가능성, 특정 문제로부터의 최대 추상화와 같은 클래스 분리를 극대화할 수 있는 패턴에 관심이 있습니다.

해결책

나는 다음을 추천합니다:

저장소 패턴
사양 패턴
의존성 주입
도메인 중심 설계

기본적으로 ALT.NET 군중이 설교하는 모든 것입니다.

다른 팁

확실히 IoC 관행과 계약 기반 일반적으로 프로그래밍은 내 목록의 맨 위에 있을 것입니다.하지만 경험의 문제로 볼 때 단순히 추상화를 위해 문제에서 너무 많이 추상화하는 것은 주의해야 합니다.예:누구나 추상화를 사용할 수 있기 때문에 추상화가 가능하지만 그렇지 않기 때문입니다.나는 그런 종류의 아키텍처가 나빠지고 시스템에 너무 높은 수준의 복잡성을 추가하여 시스템 유지 관리를 더욱 악화시키는 것을 보았습니다.

단위 테스트, 지속적인 통합 및/또는 "스크럼" 회의 등 개발 프로세스에 대한 일종의 피드백 루프입니다.나는 그것이 실제로 민첩한 "아키텍처"의 범위에 속하지 않는다는 것을 알고 있지만 민첩한 프로세스가 없다면 "민첩한 지향" 아키텍처의 정도는 중요하지 않습니다.

내가 제안한 필수 설계 관행은 먼저 건축의 기능적 인 엔드 투 엔드 골격을 구축하는 것입니다.실제 피드백을 통해 최대한 빨리 검증합니다.

이것이 바로 Pragmatic Programmers가 "Tracer Bullets"라고 부르는 것이며 Alistair Cockburn은 "걷는 해골".

애플리케이션이 어떤 상태인지 정의할 수도 있나요? 논문의 맥락을 파악할 수 있을까요?너만 고려하니? 응용 소프트웨어 또는 더 복잡한 시스템도 다루나요?

흥미로운 질문이네요.아키텍처를 독립적으로 민첩하게 만들 수 있습니까?우리가 XP와 같은 것을 보고 있다면 나는 약간 의심스럽습니다.아니면 내가 오해했을 수도 있지만, 그렇다고 해서 내가 확장되는 것을 막은 적은 없었습니다...

XP에서는 제가 더 잘 알고 있는 접근 방식을 취하기 위해 프로젝트를 시작한 후 매우 짧은 시간 내에 일종의 구조를 갖게 될 것입니다.사실 첫 번째 이야기가 완성될 때쯤이죠.초기 스토리 작성 동안 우리는 무엇을 만들 수 있는지에 대한 아이디어를 얻기 시작했습니다. 이는 불가피합니다.프로그래머는 코드 측면에서 생각하는 경향이 있습니다.하지만 너무 앞서 생각하면 우리는 야그니 지역.

나는 민첩한 환경에서 개발된 애플리케이션 아키텍처의 대부분이 특히 중복을 제거하기 위한 지속적이고 헌신적인 리팩토링을 통해 창발될 것으로 예상된다고 생각했습니다.

따라서 애자일 프로세스의 결과로 진화된 아키텍처가 표시하는 경향이 있는 특정 특성(또는 특성 클래스)이 있는지 평가하는 것이 문제일 수 있습니다.그리고 이미 언급한 원칙 중 일부(몇 개는 내가 이해하기도 함)가 그럴 가능성이 있지만 우리가 구축하는 앱의 종류에 따라 달라질 것이라고 생각합니다.

내가 아는 한 Agile은 "아키텍처"를 설교하지 않습니다.애자일은 프로젝트 관리, 릴리스 주기 및 일반 개발 관행에 영향을 미치는 기본 원칙을 기반으로 하는 방법론이지만 확실히 소프트웨어 아키텍처는 아닙니다.

여기에 나열된 모든 소프트웨어 패턴은 애자일 개발에 반하는 강력한 폭포 프로세스를 사용하여 사용할 수 있습니다.

양파 아키텍처

예

민첩하다는 것은 변화를 수용한다는 것을 의미합니다.요구 사항 및 디자인 결정의 변경을 채택하고 리팩토링 등을 허용합니다.작동 중이거나 이전에 동의한 항목을 만지고 있기 때문에 "전통적인" 방식으로 눈살을 찌푸리는 많은 것들이 있습니다.

XP와 같은 방법에서는 단위 테스트를 작성하여 품질을 높게 유지하려고 합니다.우리 모두가 단위 테스트 작성에 동의한다고 가정해 봅시다.

이제 모든 시스템을 테스트할 수 있는 것은 아니기 때문에 시스템을 테스트 가능하거나 테스트하기 쉽게 일부 아키텍처를 도입할 수 있습니다.예를 들어, 중간 레이어를 호출 가능하게 만들고 UI 레이어를 비즈니스 로직과 분리하는 등의 작업을 수행합니다.

Robert Martin이 이에 대해 할 말이 있다면(그는 IIRC 회의에서 원래 Agile 선언문을 불렀습니다), 절대적으로 아키텍처는 Agility와 관련된 모든 것을 가지고 있습니다.그의 책의 첫 번째 섹션 전체 민첩한 소프트웨어 개발, 원칙, 패턴 및 사례 에 관한 것입니다 단단한 건축 원리.이것은 일부 분기에서 다소 논란의 여지가 있었지만 그 이유를 이해하지 못합니다.코드베이스가 취약하고 결합도가 높으면 변경에 매우 개방적일 수 없습니다. 이는 민첩성의 특징입니다.개념적으로 프로세스와 코드 실습을 분리하는 것은 매우 민첩하지 못한 일입니다.

선언문의 원칙 1:"우리는 프로세스와 도구보다 개인과 상호작용을 중요하게 생각합니다."

애자일 "프로세스"를 코드베이스 아키텍처와 분리된 추상화로 정의하는 것은 이 첫 번째 원칙의 정신을 위반하는 것입니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow