Domain Driven Design en una aplicación de gestión académica

Voy a iniciar el desarrollo de una aplicación de gestión académica para un colegio. El dominio es lo suficientemente complejo como para necesitar un cambio de metodología respecto a mi modo de trabajo actual.
Hasta ahora, he trabajado a partir del framework CakePHP en su versión 1.3 con buen resultado. Sin embargo, ha llegado un momento en el que me siento limitado por el propio framework. Por lo que he visto de la versión 3, las cosas han mejorado mucho en todos los aspectos en los que he percibido esas limitaciones, pero...
El caso es que llevo unas cuantas semanas estudiando conceptos de patrones de diseño, arquitectura limpia y diseño orientado por el dominio y esto ha influido en mi manera de percibir la forma en que estoy trabajando y la forma en que quiero trabajar a partir de ahora. Vamos al grano.

Academia

El nombre provisional de mi proyecto es "Academia".
Se trata de una aplicación de gestión académica para un colegio. Esto significa que el dominio de la aplicación es mantener la información académica de los alumnos de un colegio, es decir, sus calificaciones en las diversas asignaturas, niveles y etapas que cursan, así como otras incidencias relacionadas con su actividad, como pueden ser las faltas de asistencia o puntualidad, el uso de servicios no escolares del colegio (el comedor, por ejemplo) y otras circunstancias.
Un requisito del proyecto es que las familias de los alumnos, y ellos mismos, puedan acceder a la información de sus hijos, que puedan comunicarse con el profesorado a través de este medio y que puedan acceder a diversos informes y trámites a través de una aplicación web.
Por otro lado, es necesario poder gestionar la organización académica del centro: etapas, niveles, asignaturas, clases, aulas, etc. Esto además, tiene que tener cierta flexibilidad ya que hay cambios legales y organizativos prácticamente todos los cursos. Pueden ser cambios en los planes de estudio, pero también cambios internos, como el hecho de que cada año escolar se reorganiza las tutorías y la docencia.

Primeros pasos

De momento, no voy a tomar ninguna decisión técnica. Es decir, no voy a elegir un framework o una solución concreta de persistencia. Uno de los problemas que puedo tener a la hora de hacer este cambio de metodología de desarrollo es tener un modo de pensar condicionado por lo que son detalles de implementación. Por otro lado, en una arquitectura limpia todos estos detalles estarían aislados de tal modo que podrían cambiarse por otras soluciones, reescribiendo sólo aquellos adaptadores necesarios.
En el Diseño Orientado por el Dominio hay que empezar por el dominio de la aplicación, entender qué es aquello de lo que se ocupa la aplicación y el primer paso para lograrlo es definir el Lenguaje Ubicuo.

Entorno

Con todo, algunas decisiones técnicas sí he empezado a tomarlas:
La primera es el lenguaje, que será PHP 5.5, he aquí un método para instalarlo.
La segunda es utilizar Composer para gestionar las dependencias del proyecto. Composer es una opción que se está generalizando y todos los grandes proyectos, bibliotecas, frameworks, etc. le están dando soporte. Además, Composer proporciona una solución de autoloader basada en Espacios de Nombres que me viene muy bien.
La tercera es utilizar PHPUnit para los test unitarios. Hasta ahora, venía usando SimpleTest a través de la CakeTest, pero está claro que PHPUnit es el camino a seguir en el sentido de que, al igual que Composer, se está convirtiendo en un estándar.
Voy a poner dos entradas acerca de la instalación de Composer y PHPUnit, así como de los primeros pasos que he ido dando con estas herramientas.

Lo siguiente...

En la próxima entrada tratará sobre el lenguaje ubicuo de Academia y los primeros problemas con el modelado del dominio.