Como separar de maneira limpa diferentes partes de um aplicativo de software?

Estou projetando um novo aplicativo que lida com muita lógica de negócios.

Para evitar o emaranhamento habitual entre diferentes camadas de aplicativos que frequentemente se infiltram nesses sistemas ao longo do tempo, quero implementar uma separação limpa de preocupações desde o início. De um modo geral, quero separar:

camada de apresentação
camada de lógica de negócios
camada de armazenamento e persistência de dados

A questão com a qual mais estou enfrentando é como realmente implementar o comportamento nas bordas de maneira limpa, principalmente entre os negócios e a camada de dados. Já vi muitos aplicativos em que a camada de dados entrega objetos ORM à camada principal, acoplando efetivamente a lógica de negócios ao ORM.

Devo converter objetos ORM para algum formato serializado (JSON?) E desserializar isso na camada de negócios em uma estrutura de dados interna a essa camada? Isso não é muita sobrecarga?

Como você implementa de maneira limpa a separação de preocupações para aplicativos de tamanho médio? Algum conselho?

design separation-of-concerns modularization

— BM
fonte

O que são objetos ORM? Um ORM normalmente mapeia dados para objetos de domínio que não estão fortemente acoplados à camada de acesso a dados, portanto, não deve haver nenhum problema em transmiti-los para a camada de negócios. Obviamente, a infraestrutura do ORM em si não deve ser passada para a camada de negócios.

— JacquesB

Vejo muitas classes de geração automática de ORMs que mapeiam o esquema do banco de dados 1: 1, por exemplo article.getId(), article.getTimestamp()etc. Esses mapeamentos parecem mais frequentemente do que não específicos do ORM usado.

— BM

Você provavelmente deve mudar o ORM. Qual ORM você está usando?

— JacquesB

Não decidiu sobre um ORM para este projeto ainda, mas eu tenho trabalhado com alguns: SQLAlchemy, SQLObject, Django ORM, Propel, ...

— BM

Você encontra sugestões detalhadas sobre isso na descrição do tio Bob de uma arquitetura limpa . Os parágrafos "ultrapassando limites" e "Quais dados ultrapassam os limites" estão exatamente lidando com o seu problema.

— Doc Brown

Respostas:

Sempre há um acoplamento lógico entre a lógica de negócios e o banco de dados. Seus esforços devem se concentrar na prevenção de um acoplamento físico .

Por exemplo, considere a regra de negócios muito básica de que cada usuário deve ter um ID de usuário exclusivo. Você pode tentar impor essa regra na camada de negócios, mas sempre haverá um cenário em que vários usuários podem tentar o mesmo ID de usuário ao mesmo tempo e o único local onde você pode verificar a exclusividade e reservar um ID de usuário em um maneira atômica está no banco de dados.

Agora, a camada de negócios não precisa saber o nome da tabela ou da coluna, nem mesmo se os usuários estão armazenados em um banco de dados (eles podem, por exemplo, ser armazenados no Active Directory, para um aplicativo de intranet). Somente a camada de acesso a dados deve saber disso. Mas gastar muito esforço desconectando o esquema das regras de negócios provavelmente é um esforço desperdiçado.

— John Wu
fonte

Guids já existem há algum tempo

— Ewan

Verifique se os objetos do Modelo de Negócios estão em sua própria biblioteca, que não faz referência a nenhum ORM ou cliente de banco de dados.

Use o padrão Repository e faça referência apenas às interfaces dos repositórios em seu código principal.

Tenha uma biblioteca de repositório concreto completamente separada, específica para o datalayer, que faça referência à biblioteca de interface, à biblioteca de modelos de negócios e ao cliente de banco de dados.

— Ewan
fonte