¿Cómo organizar múltiples proyectos en una base de código con lógica compartida, en Python? Si tiene una aplicación web y algunos servicios de fondo que hablan con las mismas bases de datos y comparten la lógica, ¿es malo una sola base de código? ¿Deberían dividirse en bases de código separadas?

Creo firmemente que cada base de datos debe tener un servicio “propietario” que sea responsable de su esquema, migraciones, lógica del modelo central, etc. Nunca debería haber ninguna duda de dónde está.

Más allá de eso, depende del tamaño, la complejidad y la escala de sus sistemas. Según la respuesta de Mattias, tener una arquitectura orientada al servicio con muchos módulos bien definidos es fundamental en la escala en la que están trabajando. Pero también hay un costo para esa arquitectura. Debe desarrollar API para la comunicación entre servicios, es probable que las API tengan que ser compatibles con versiones anteriores, la implementación y la supervisión se vuelvan más complejas, etc.

Lo mismo se aplica a los repositorios. Mientras tenga un repositorio, sabrá que cada vez que realiza una confirmación, toda su base de código se encuentra en un estado particular. Si tiene múltiples repositorios, puede enviar un cambio a un repositorio que divide las cosas en un repositorio diferente. Esto puede ser un desafío si tiene un equipo de personas trabajando en diferentes partes del sistema, y ​​cada uno puede tener versiones diferentes de todos los repos desprotegidos.

Yo diría que mientras funcione, use un único repositorio, pero intente dividir su código en módulos independientes en ese repositorio. De esa forma, si desea extraer una parte del código en su propio repositorio, se requiere una cantidad mínima de reescritura.

Cada proyecto tiene sus propias peculiaridades, pero una forma en que podría considerar hacer esto es tener cada unidad principal estructurada como su propia base de código / repositorio y unirlas usando submódulos git . Los submódulos pueden ser difíciles de usar y, si no se usan correctamente, pueden convertirse rápidamente en una pesadilla de mantenimiento; así que lee y practica bien antes de seguir este camino.

Por código base, supongo que quiere decir: “¿debería ser un único repositorio en el scm que utiliza”.
Comenzaría simple y tendría un solo repositorio. Esto le permitirá bifurcar y refactorizar el código que cruza el frontend y el backend sin tener que crear revisiones rotas.
Si prevé tener cantidades extremadamente grandes de código, debería considerar dividir el código en componentes que tienen menos probabilidades de requerir cambios transversales.
Recuerde que, al menos en el caso de git, no puede extraer una copia escasa (es decir, solo un subárbol), de modo que cuando las personas frontend comprueben su código, también obtendrán el código de fondo. Esto puede ser importante para usted, pero generalmente no lo es.

Soy un novato relativo. Pero aprendo rápido y tengo la suerte de trabajar para un par de personas brillantes. Miro y escucho con mucha atención. He aprendido que compartir código / datos / módulos entre diferentes proyectos es una mala idea. Vi a mi brillante jefe hacer esto con nuestro código marco y escuché sus maldiciones mientras aprendía a arrepentirse. Yo mismo he tratado de poner un único control perfecto para múltiples usos en una aplicación compleja y no fue bueno. No ahorra tiempo. En absoluto.