시스템을 디자인 할 때 사용할 프레임 워크를 중심으로 디자인을 제공하는 것이 가장 좋은 방법입니까?

특정 프레임 워크와 함께 사용할 시스템 또는 응용 프로그램을 개발할 때 프레임 워크를 염두에 두지 않고 시스템을 디자인하는 것이 가장 좋은 방법입니까, 아니면 "프레임 워크가 더 쉬울 것입니다"라는 사고 방식으로 시스템을 디자인하는 것이 좋습니다 이것으로 "

development-process systems

— 로버트 파운드
소스

어떤 종류의 프레임 워크에 대해 이야기하고 있습니까? 특정 산업의 도메인 특정 문제를 해결하도록 설계된 틈새 비즈니스 별 프레임 워크를 의미합니까? (예 : 의료, 핵, 방위, 항공 등). 아니면 기술적 인 문제를 해결하기 위해 설계된 범용 프레임 워크에 대해 이야기하고 있습니까?

— Ben Cottrell

기술적 문제를 해결하기 위해 설계된 범용 프레임 워크

— Robert Pounder

시간이 부족한 소규모 (저는 작업 중이며 나중에 자세히 설명 할 수 있음) : 디자인을 기반으로 전자 메일을 생성하는 시스템을 작성 중입니다. -Laravel에서이 글을 쓰고 있다면 이메일을 디자인 할 때 템플릿 엔진 "블레이드"를 사용하여 시스템 설계가 흐름 측면에서 훨씬 간단 해집니다. 그러나 바닐라 PHP를 사용하거나 다른 적절한 대체 템플릿 시스템을 찾으면 템플릿 엔진을 작성해야합니다. 그것은 디자인 프로세스에 추가 될 것이며,이 질문도 언급하고 있습니다.

— Robert Pounder

이 질문은 "프레임 워크"와 "디자인"이 업계에서 여러 가지 의미로 오버로드 된 단어이기 때문에 크게 다른 답변을 생성 할 것입니다. 또한 "기술적 문제를 해결하기 위해 설계된 범용 프레임 워크"로 프레임 워크를 단일 정의한 경우에도 특정 프레임 워크에 의존하게됩니다.

— stannius

바퀴 달린 대중 교통 차량을 설계하려고 생각하는 동안 길을 잃는 동안 버스에 부딪 치는 것은 너무 나쁠 것입니다.

답변:

고객의 디자인 은 고객의 요구를 최대한 밀접하게 충족시켜야합니다. 디자인에는 다음과 같은 작은 것들이 포함되어 있습니다.

사용자 경험
기능성
응용 프로그램 조각이 자체 또는 외부 엔터티와 통신하는 방법

이러한 것들 중 어느 것도 프레임 워크에 의해 지시되어서는 안됩니다. 이러한 목표를 달성하기 위해 프레임 워크와 싸우는 것이 확실하다면 코드 작성을 시작하기 전에 해당 목표를 달성하는 데 도움이되는 새로운 프레임 워크를 선택해야합니다.

적절한 툴셋 (프레임 워크는 툴)을 선택한 후에는 툴을 사용하도록 설계된 방식으로 사용하는 것이 좋습니다. 프레임 워크 디자인에서 멀어 질수록 팀의 학습 곡선이 커지고 무언가 잘못 될 가능성이 커집니다.

한마디로

사용자를위한 디자인
디자인을 달성하기 위해 적절한 도구를 선택하십시오
도구를 사용하도록 설계된 방식으로 사용하십시오

추가 생각 :

20 년 이상의 소프트웨어 엔지니어링과 여러 프레임 워크를 사용한 후 몇 가지 교훈을 얻었습니다. 모든 프레임 워크는 양면 칼입니다. 위에서 언급 한 큰 3을보기 전에 프레임 워크를 결정하는 문제는 평범한 (최상의) 사용자에게 좋은 사용자 경험을 손상시킬 수 있다는 것입니다. 또는 특정 기능을 수행하기 위해 프레임 워크 디자인에서 벗어나야 할 수도 있습니다.

— 베린 로리 치
소스

그런 다음 클라이언트와 협상을해야합니다. 그들이 부과 한 제약으로 할 수있는 것과 할 수없는 것을 설명하십시오. X 프레임 워크 를 선택하면 어떻게 변할 수 있는지 제안하십시오 . 그들은 기꺼이 변하지 않을 것이며, 경험이 저조한 삶을 기꺼이 살려고 할 것입니다. 또는 그들은 당신이 무엇을하고 있는지 알고 당신을 믿기로 결정할 수 있습니다. 클라이언트에 따라 다릅니다. 하루가 끝나면 기대치를 관리합니다.

— Berin Loritsch

시스템 설계와 세부 설계와 같은 여러 레벨의 설계간에 혼동이있는 것 같습니다. 나 에게이 질문은 시스템 (인터페이스, 동시성, 데이터 볼륨, 사용자 인터페이스, 사용자 유형) 대신 세부 디자인 (구현 방법)에 대해 묻고있었습니다.

— Gusdor

질문이 "기술 설계"로 바뀌면 언어와 운영 체제가 설계에 약간의 추론이있을 수 있습니다. 그러나 여전히 디자인은 구현이 아닙니다. 만약 당신이 프레임 워크 기능을 생각하고 있다면, 그것은 디자인이 아니라, 함정입니다. 프레임 워크 강도에 따라 디자인 결정을 내리는 경우 약점을 겪을 준비를하십시오. 그리고 약점이 요구 사항을 충족하면 큰 문제가 있습니다. 가장 큰 회사는 즐거움을 위해 자신의 프레임 워크를 구축하지 않았습니다.

— Laiv

@ Laiv 좋은 의견! 실제로, 그것은 "일부와 일부"입니다. 네일 건과 스크류 건은 모두 물건을 고정시킬 수 있습니다. 하나는 다른 것보다 가역적이며 느리게 작동하며 더 복잡합니다. 사람들이하는 모든 선택은 불가피하게 트레이드 오프입니다. 당신은 돈을 지불하고 당신은 기회를 잡습니다.

@RobertPounder, 시스템 을 설계하는 동안 솔루션에 대한 적합성을 결정해야하는 도구입니다 . 프레임 워크가 디자인에 영향을 줄 수있는 방법을 이해하지만이를 지시해서는 안됩니다.

— Berin Loritsch

프레임 워크는 당연히 특정 모듈 과 하위 시스템 (예 : GUI 프론트 엔드) 의 디자인에 영향을줍니다 . 다른 답변에서 언급했듯이 선택한 프레임 워크와 싸우고 있다면 어려움을 겪을 것입니다.

그러나보다 광범위하게는 단일 프레임 워크 나 기술이 전체 시스템 아키텍처의 "큰 그림"을 지시하거나 추진하지 않도록해야합니다. 대부분의 범용 응용 프로그램 프레임 워크는이를 장려하지 않으므로 한 시스템 주위에 전체 시스템을 작성하는 경우 해당 프레임 워크 작성자가 의도하지 않은 작업을 수행하고있을 것입니다.

다른 문제를 해결하기 위해 많은 다른 프레임 워크를 사용할 것입니다. 시스템이 더욱 복잡 해짐에 따라 Big Ball Of Mud 를 만들지 않도록주의해야합니다 . 가능하면 시스템을 모듈 식으로 느슨하게 연결하십시오. 일부 프레임 워크는 프레임 워크 별 워크 플로우를 다른 구성 요소에서 '숨기는'래퍼 및 어댑터를 작성하여 추상화 뒤에 더 잘 유지 될 수 있습니다. GUI 툴킷은 프론트 엔드 GUI 기능 만 제공하는 경향이 있으므로 이러한 GUI 모듈은 시스템의 나머지 부분과 떨어져 있어야합니다.

범용 프레임 워크 (UI 프레임 워크, 데이터 계층 프레임 워크 등)는 시스템의 전체 아키텍처를 규정하기 위해 존재하지 않으며, 대부분 컴포넌트 또는 모듈의 설계를 규정 할 수 있습니다. 예를 들어, 일부 GUI 기술은 특정 MV * 패턴에 맞춰져 있습니다.

시스템의 전체 아키텍처는 주로 비즈니스 요구 사항에 따라 결정되어야합니다 . 모든 것을 하나로 묶기 위해 특정 도구 (예 : 메시징 미들웨어 도구 또는 ORM 프레임 워크)에 크게 의존하고 있지만 '서비스'클래스와 같은 추상화로 프레임 워크를 캡슐화 한 경우 '제한이있을 때 해당 프레임 워크의 제약을받을 가능성이 줄어 듭니다.

큰 그림 디자인을 위해 다음 사항을 명심하십시오.

모듈 식 소프트웨어 구축 목표
각 모듈과 구성 요소를 작성할 때 우려 사항 분리 고려
시스템을 계층으로 분리하기 위해 멀티 티어 아키텍처 고려
새는 추상화를 구축하지 마십시오
이 관련 질문에 대한 약어 : DRY, KISS, SOLID 등은 무엇으로 분류됩니까?

— 벤 코텔
소스

때로는 일부 프레임 워크 작성자가 사용자가 프레임 워크와 함께 응용 프로그램 코드를 작성하는 것을 전혀 신경 쓰지 않는 것 같습니다.

— COME

@COMEFROM-코드를 프레임 워크에 단단히 연결하는 것은 개발자가 처음에 설계했던 것과 동일한 문제를 해결하기 위해 프레임 워크를 선택했다고 가정하기 때문에 권장됩니다.

— JeffO

디자인 원칙에서 코딩 원칙에 이르기까지 약간의 주제를 벗어 났지만 비즈니스 요구 사항이 특정 프레임 워크를 사용해야하는 경우 어떻게 말합니까? (회사 아웃소싱과 사내 개발자는 하나의 언어 만 알고 있다고 생각합니다.) 나는 원래 게시물에서 이것을 분명히해야한다고 생각합니다.

— Robert Pounder

@RobertPounder 내가하려고했던 진짜 요점은 사람들이 때로는 특정 프레임 워크를 전체 애플리케이션의 '접지'로 사용하려는 경향이 있다는 것입니다. 관련없는 코드가 해당 프레임 워크에 부적절하게 융합되었습니다. 예를 들어 비즈니스 로직이 UI 컨트롤과 결합되어 당시에는 쉽지 않았기 때문입니다. 매우 쉬운 일이므로 조심해야합니다

— Ben Cottrell

나는 @nocomprende에 동의하지 않아야한다. 미래의 모든 요구 사항을 예측할 수있는 것은 아니지만 이전 소프트웨어 를 확장 / 유지하기 가 너무 어려워 시스템을 간단히 다시 작성하기도합니다 .

— SeldomNeedy

그렇습니다 . 프레임 워크가 "알고있는 것"에 최대한 가깝게 붙어 있어야합니다 .

그 이유는 단순히 "생각"하는 방식으로 프레임 워크를 고수할수록 해당 프레임 워크를 사용하는 문제 / 아이디어에 대해 다른 개발자와 더 쉽게 대화 할 수 있기 때문입니다.

나중에 사용하는 다른 사람들의 상호 운용성과 사용 편의성을 높이고, 사용하는 모든 개념의 기본 철학을 고수하면 자습서 또는 일반적인 솔루션을 더 잘 이해하고 통합 할 수 있습니다.

프레임 워크를 "파괴"하는 이유를 생각할 수있는 유일한 이유는 "기본"구성 / 원칙 적용을 통해 제공 할 수없는 것이 절대적으로 필요하기 때문입니다. 그러나 시작하기에 올바른 틀이 아닐 수도 있습니다.

기본적으로 이것은 다른 결정에도 적용될 수 있습니다. 다른 사람과 같은 언어를 사용하면 더 쉽게 사용할 수 있기 때문에 사용하려는 언어를 사용하려는 언어와 비슷하게 사용해야합니다 .

— FP
소스

질문의 변경으로 인해 답변을 검토해야 할 수 있습니다. 귀하의 답변은 실제로 OP의 질문에 답변하지 않습니다.

— Laiv

@Laiv 주제에 대한 귀하의 의견과 일치하지 않더라도 여전히 질문에 대한 답변이 아닙니다. 해당 주제의 상충되는 특성을 표시하기 위해 자신의 답변을 작성하는 것이 가장 좋습니다.

— FP

내가 잘 설명하지 않았다면 실례합니다. 나는 영어를 유창하지 못합니다. 나는 단지 IMO, 질문과 대답이 다른 것들에 대해 말하고 싶다고 말하고 싶었습니다. 그렇지 않다고 생각하면 괜찮습니다. 나는 그것을 주장하지 않을 것이다. 그게 다야.

— Laiv

이것은 절대적입니다. 도메인 별 언어 및 유사한 아이디어의 작동 방식과 유사합니다. 귀하의 제품은 다른 방식이 아닌 도구 (프레임 워크)에 의해 형성됩니다. 프레임 워크 "승리". 결혼 할 수 없다면 다른 것을 선택하십시오. (힌트 : 이상적인 프레임 워크 가 없습니다 . 그냥 말하십시오.)

디자인은 다른 프레임 워크가 아닌 선택한 프레임 워크 (있는 경우)에 영향을 미칩니다.

— RubberDuck