Ao projetar um sistema, é uma prática recomendada atender o design em torno da estrutura que você usará?

Ao desenvolver um sistema ou aplicativo que você planeja usar com uma certa estrutura, é uma prática recomendada projetar o sistema sem a estrutura em mente ou é melhor projetar o sistema com a mentalidade "bem, a estrutura teria um tempo mais fácil com isso".

development-process systems

— Robert Pounder
fonte

De que tipo de estrutura você está falando? Você quer dizer alguma estrutura específica de negócio de nicho, projetada para resolver problemas muito específicos de domínio para um setor específico? (por exemplo, médico, nuclear, defesa, aviação, etc.). Ou você está falando de estruturas de uso geral projetadas para resolver problemas técnicos?

— precisa

estruturas de uso geral projetado para resolver problemas técnicos

— Robert Pounder

Pequena escala por falta de tempo (estou no trabalho, pode ser elaborado mais tarde): estou escrevendo um sistema que gera e-mails com base em projetos. - Se eu estivesse escrevendo isso no Laravel, provavelmente usaria o "blade" do mecanismo de modelagem para projetar os emails, o que tornaria o design do sistema muito mais simples em termos de fluxo. No entanto, eu teria que escrever um mecanismo de modelagem se estivesse fazendo baunilha PHP ou encontrando outro sistema de modelagem alternativo adequado. Isso aumentaria o processo de design, ao qual a pergunta também está se referindo.

— Robert Pounder

Essa pergunta vai gerar um monte de respostas muito diferentes, porque "estrutura" e "design" são palavras sobrecarregadas com múltiplos significados em nossa indústria. Além disso, mesmo para uma definição única de estrutura como "estruturas de uso geral projetadas para resolver problemas técnicos", isso dependerá da estrutura específica - algumas estruturas são mais opinativas do que outras.

— Stannius

Seria muito ruim ser atropelado por um ônibus enquanto perdia a cabeça ao tentar projetar um veículo de transporte público com rodas.

Respostas:

Seu design deve atender às necessidades dos clientes o mais próximo possível. Lembre-se de que o design inclui pequenas coisas como:

Experiência de usuário
Funcionalidade
Como as partes do seu aplicativo se comunicam (com ele ou com entidades externas)

Nenhuma dessas coisas deve ser ditada pela estrutura. Se estiver claro que você estará lutando com sua estrutura para atingir esses objetivos, escolha uma nova estrutura que o ajudará a atingir esses objetivos antes de começar a escrever o código.

Depois de escolher um conjunto de ferramentas apropriado (a estrutura é uma ferramenta), recomendo usar as ferramentas da maneira como elas foram projetadas para serem usadas. Quanto mais você se desvia do design da estrutura, mais aumenta a curva de aprendizado da sua equipe e maior a chance de algo dar errado.

Em resumo

Design para seus usuários
Escolha as ferramentas apropriadas para realizar seu projeto
Use suas ferramentas da maneira que elas foram projetadas para serem usadas

Pensamentos adicionais:

Após mais de 20 anos de engenharia de software e usando várias estruturas, aprendi algumas lições. Todas as estruturas são uma faca de dois gumes: ambas restringem e permitem. O problema com a decisão de sua estrutura antes de analisar os 3 grandes mencionados acima é que você pode comprometer uma boa experiência do usuário para uma medíocre (na melhor das hipóteses). Ou você pode ser forçado a desviar-se do design de estruturas para obter algumas funcionalidades específicas.

— Berin Loritsch
fonte

Então você precisa fazer algumas negociações com o cliente. Explique o que você pode ou não fazer com as restrições que eles impuseram. Propor como isso pode mudar se você escolher a estrutura X. Eles podem não estar dispostos a mudar e estão dispostos a viver com uma experiência degradada. Ou eles podem decidir que você sabe o que está fazendo e confiar em você. Isso depende do cliente. No final do dia, você gerencia as expectativas deles.

— precisa saber é o seguinte

Parece haver alguma confusão entre os diferentes níveis de design aqui: design de sistema e design detalhado. Para mim, essa pergunta era sobre o design detalhado (o método de implementação) e não o sistema (interfaces, simultaneidade, volume de dados, interface do usuário, tipo de usuário).

— Gusdor

Se a pergunta gira em torno de "design técnico", o idioma e o SO podem ter algumas inferências no design. Mas ainda assim, o design não é implementação. Se você está pensando nos recursos do Frameworks, não é design, é implentação. Se você basear suas decisões de design nas forças da estrutura, prepare-se para sofrer sua fraqueza. E quando a fraqueza atende aos requisitos, você tem um enorme problema. As maiores empresas não construíram estruturas próprias por prazer.

— LAIV

@Laiv Ótimo comentário! Realmente, é "alguns e alguns". Uma pistola de pregos e uma pistola de fenda podem prender coisas, uma é mais reversível que a outra e também trabalha mais devagar e é mais complexa. Toda escolha que as pessoas fazem é inevitavelmente uma troca. Você paga seu dinheiro e se arrisca.

@RobertPounder, é uma ferramenta cuja adequação de uma solução precisa ser decidida ao projetar o sistema. Entendo como as estruturas podem influenciar o design, mas não devem ditá-lo.

— Berin Loritsch

Estruturas naturalmente influenciam o design de módulos e subsistemas específicos (como um front-end da GUI). Como a outra resposta mencionada, você terá dificuldades se lutar contra o (s) quadro (s) escolhido (s).

No entanto, de maneira mais ampla, você deve evitar deixar que uma única estrutura ou tecnologia imponha ou conduza o "quadro geral" da arquitetura geral do sistema. A maioria das estruturas de aplicativos de uso geral não incentiva isso; portanto, se você estiver escrevendo todo o sistema em torno de uma estrutura, provavelmente estará fazendo algo que os autores dessa estrutura não pretendiam.

Você provavelmente usará muitas estruturas diferentes para resolver problemas diferentes; À medida que seu sistema se torna mais complexo, você precisa ter cuidado para não criar a Big Ball Of Mud . Sempre que possível, mantenha seu sistema modular e pouco acoplado. Algumas estruturas podem ser melhor mantidas atrás das abstrações gravando wrappers e adaptadores que 'ocultam' os fluxos de trabalho específicos da estrutura de outros componentes. Os kits de ferramentas da GUI tendem a servir apenas a funcionalidade da interface gráfica do usuário, portanto, esses módulos da GUI devem ser mantidos afastados do resto do sistema.

Estruturas de uso geral (como estruturas da interface do usuário, estruturas da camada de dados etc.) não existem para prescrever a arquitetura completa do seu sistema - no máximo, podem prescrever o design de um componente ou módulo; por exemplo, algumas tecnologias de GUI são voltadas para padrões específicos de MV *.

A arquitetura geral do seu sistema deve ser orientada principalmente pelos requisitos de negócios . Você pode se apoiar fortemente em uma ferramenta específica (por exemplo, uma ferramenta de middleware de mensagens ou uma estrutura ORM) para amarrar tudo, mas se você encapsulou a estrutura em uma abstração como uma classe 'service' é menos provável que você se sinta constrangido por essa estrutura quando encontrar suas limitações.

Tente ter em mente o seguinte para seu design geral:

Objetivo de construir software Modular
Considere a Separação de Preocupações ao escrever cada módulo e componente
Considere a arquitetura multicamada para separar o sistema em camadas
Não crie abstrações com vazamento
As siglas nesta pergunta relacionada : Como são classificados DRY, KISS, SOLID etc.?

— Ben Cottrell
fonte

Às vezes, parece que alguns autores da estrutura não se importam com o fato de seus usuários escreverem o código do aplicativo em conjunto com a estrutura.

— Venha de

@COMEFROM - O acoplamento estreito do seu código a uma estrutura seria incentivado pelos desenvolvedores, porque eles assumem que você escolheu a estrutura para resolver os mesmos problemas para os quais eles a projetaram.

— Jeffo

Você ficou um pouco fora do assunto, indo dos princípios de design aos princípios de codificação, mas eu entendo o que você está dizendo, e se o requisito de negócios for o uso de uma certa estrutura? (acho que a terceirização da empresa e os desenvolvedores internos conhecem apenas um idioma). Acho que deveria deixar isso mais claro no post original.

— Robert Pounder

@RobertPounder O ponto real que eu estava tentando entender (talvez não muito bem) é que às vezes há uma tendência para as pessoas usarem estruturas particulares como um 'fundamento' para toda a sua aplicação - o que inevitavelmente leva à lógica de negócios e outras código não relacionado sendo inadequadamente fundido a essa estrutura - por exemplo, a lógica de negócios sendo acoplada aos controles da interface do usuário apenas porque era rápido e fácil na época. É muito fácil de fazer isso, por isso é algo para ser cauteloso

— Ben Cottrell

Devo discordar de @nocomprende aqui; nem todos os requisitos futuros podem ser previstos, mas às vezes os sistemas são reescritos simplesmente porque o software anterior é muito difícil de estender / manter .

— precisa saber é o seguinte

Sim, você deve ficar o mais próximo possível do que a estrutura "diz" para você fazer.

A razão é simplesmente que, quanto mais você se aproximar da maneira de "pensar" da estrutura, mais fácil você poderá conversar com outros desenvolvedores sobre seus problemas / idéias que também usam essa estrutura.

Você aumenta a interoperabilidade e a facilidade de uso para outras pessoas que o usam posteriormente, entenderá e incorporará melhor os tutoriais ou soluções comuns se seguir a filosofia subjacente do que quer que esteja usando.

A única boa razão pela qual consigo pensar por que você "quebraria" a estrutura é que você absolutamente precisa de algo que ela não pode fornecer, dada sua configuração / aplicação "padrão" de princípios. Mas, então, pode não ser a estrutura certa para começar.

Basicamente, isso pode ser aplicado a outras decisões também. Você deve usar o idioma que você está usando, tanto quanto ele está destinado a ser utilizado, porque isso torna as coisas mais fácil se você está falando a mesma língua que todos os outros.

— FP
fonte

Pode ser que você revise sua resposta devido a alterações na pergunta. Sua resposta, na verdade, não responde à pergunta do OP.

— LAIV

@ Laiv Não vejo como ele não responde à pergunta, embora possa não corresponder à sua opinião sobre o assunto, ainda é uma resposta. Você pode escrever sua própria resposta para mostrar a natureza conflitante do tópico em questão.

— FP

Com licença, se eu não me explicasse bem. Eu não sou tão fluente em inglês quanto gostaria de ser. Eu só queria dizer que, na OMI, a pergunta e sua resposta falam de coisas diferentes. Se você acha que não, está tudo bem. Eu não vou discutir isso. É isso aí.

— LAIV

É absolutamente isso. É semelhante à forma como funcionam os idiomas específicos do domínio e idéias semelhantes. Seus produtos são modelados pela ferramenta (Framework) e não o contrário. O Framework "vence". Se você não pode se casar, escolha outro. (Dica: não há ideal Framework apenas sayin'..)

Seu design deve influenciar a estrutura escolhida (se houver!), E não o contrário.

— precisa