Elegir entre una biblioteca y un archivo ejecutable es relativamente simple: ¿tiene sentido ejecutar el código que desea poner en un ejecutable como un programa independiente? Si no, probablemente debería ser una biblioteca. En general, preferiría una capa ejecutable delgada sobre tantas bibliotecas como sea necesario, ya que eso hace que sea más fácil reutilizar esas bibliotecas de fondo más tarde y no están vinculadas a un programa en particular.
En cuanto a decidir cómo dividir su código entre bibliotecas, puede encontrar útil el artículo del tío Bob Martin sobre granularidad .
En él habla sobre la estructura OO y define varios principios que pueden ayudarlo a empaquetar su código de manera adecuada. Estos también se cubren con más detalle en su libro, Principios ágiles, patrones y prácticas en C # .
Resumiré los principios a continuación:
El Principio de Equivalencia de Reutilización / Liberación (REP)
El gránulo de reutilización es el gránulo de liberación. Solo los componentes que se liberan a través de un sistema de seguimiento pueden reutilizarse de manera efectiva. Este gránulo es el paquete.
El tío Bob define la reutilización como la capacidad de vincular estática o dinámicamente la biblioteca reutilizada en su programa y nunca tener que mirar su código fuente. Cuando se lanza una nueva versión de la biblioteca, puede integrarla en su sistema.
El tratamiento de las bibliotecas de esta manera conduce solo a mantener las cosas relacionadas juntas en el mismo paquete. De lo contrario, los consumidores de la biblioteca podrían tener que actualizar a una nueva versión sin ningún motivo o retrasarse algunas versiones.
El principio de reutilización común (CRP)
Las clases en un paquete se reutilizan juntas. Si reutiliza una de las clases en un paquete, las reutiliza todas.
Este principio es compatible con el anterior. Si tiene clases en el mismo paquete que no están relacionadas entre sí, puede estar obligando a los usuarios de su biblioteca a actualizar innecesariamente.
El principio de cierre común (PCC)
Las clases en un paquete deben cerrarse contra los mismos tipos de cambios. Un cambio que afecta a un paquete afecta a todas las clases en ese paquete.
Este principio habla de mantenibilidad. La idea aquí es agrupar las clases en función de cómo podrían necesitar cambiar. De esa forma, sus cambios se pueden localizar en una parte de la aplicación y no extenderse por todas partes.
El Principio de Dependencias Acíclicas (ACP)
La estructura de dependencia entre paquetes debe ser un Gráfico Acíclico Dirigido (DAG). Es decir, no debe haber ciclos en la estructura de dependencia.
No permitir dependencias cíclicas permite que cada paquete se desarrolle de forma independiente y se "libere" al resto de la compañía cuando estén listos los nuevos cambios. De esta manera no terminas con dos equipos estancados, esperando el uno al otro para terminar un trabajo.