Cita:
Empezado por roman
Más que nada era un ejemplo pues a mi al menos. me parece justamente que no siempre queda claro qué camino tomar.
En este ejemplo, desde luego hay reglas que seguir, por eso dije que no se hace así como así; no todos los alumnos se pueden inscribir a cualquier curso, se debe tener en cuenta qué tipo de alumno es, cuál es su historia académica, cuántos cursos más lleva, etc.
Ahora, en algunos casos el alumno puede inscribirse él mismo, pero en otros es un personal calificado quien debe hacerlo y en otros más es un proceso automático (algunas reinscripciones), pero en todas las modalidades se deben cumplir una serie de reglas.
No sé qué se entendería porque el proceso en sí tenga un valor de negocio, en mi ingenuidad considero que lo tiene en tanto que existe. Una inscripción es un ente en sí mismo con determinados atributos como la calificación, la fecha en que se realiza, la fecha en que se paga, etc.
Luego entonces ¿sería descabellado poner:
Código Delphi [-]Inscripcion := TInscripcion.Create; Inscripcion.Alumno:= Alumno; Inscripción.Curso := Curso; if Inscripcion.Validar then Inscripcion.Guardar;
de manera que es el mismo objeto Inscripcion el que valida las reglas?
// Saludos |
Que el proceso tenga valor de negocio significa que para el ambiente o dominio le es útil y representa un elemento más que forma parte de su trabajo, es parte de la organización y/o le da valor agregado.
Una inscripción tiene, al menos yo creo que si, que tiene valor de negocio. Es una actividad central y afecta en otras áreas. Por tanto, es de importancia dos cosas aqui: el proceso y el documento. Es necesario contar con un método que permite dar soporte a esta actividad. Por ejemplo, el nombre InscribirAlumno. Ahora, como valor de negocio, el documento o formulario que se llena es la FichaInscripcion. Puede que realizar una clase que represente a dicho documento les sea de utilidad en un futuro... por ahora no estaría mal añadirla al repertorio.
Entonces, si lo veo asi, yo diría que tenemos las siguientes clases: Alumno, Grupo, FichaInscripcion.
Se estuvo debatiendo la idea de que exista una clase que determine las reglas de inscripción.
Tu enfoque, amigo roman, no es descabellado. Es entendible y si te es una representación viable del dominio, pues sigue.
Si me lo permites, yo lo veo un tanto distinto. Si bien se puede entender que el alumno es el interesado en llevar el método de incribirse (es posiblemente el experto en información), si realmente existe un conjunto de reglas que afectan a esto, yo sugeriría que no posee toda la información necesaria para llevar a cabo dicho propósito. Que sea un experto parcial no es un gran problema, pero a vista de la presencia de la volatilidad de este proceso, es mejor ubicar el grueso del problema de la regla en otro lado.
Es entendible que el interesado sea el alumno, más termina no siendo el quien decide y lleva a cabo el proceso. Puede entenderse, si se le desea verlo (y buscarle una quinta pata al problema
), que entre el alumno y el proceso medie algún interesado. Este intermediario muy posiblemente sea el candidato potencial para asumir el proceso estudiado: es el quien tiene más conocimiento e información de como tratar el tema. Ando pensando en un nombre que sea más representativo... si es que en ocasiones es otra persona quien llena la ficha, en otras el estudiante, y en otras una máquina (buscarle la octava
)... yo diría que conviene llamarlo ProcesadorInscripcion (ya me diran si el estudio del dominio sugiere otro nombre. Al menos yo lo veo que tantos actores humanos y no humanos hacen uso del ProcesadorInscripcion)
Es este ProcesadorInscripcion quien en definitiva realiza la inscripción. En resumidas cuentas, el algoritmo para mi puede venir así:
Código Delphi
[-]procedure TProcesadorInscripcion.InscribirAlumno(Alumno: TAlumno, Grupo: TGrupo);
var Ficha: TFichaInscripcion;
begin
if MotorReglaInscripcion.EsValidaInscripcion(Alumno, Grupo)
then begin
Ficha := TFichaInscripcion.Create;
Ficha.Alumno := Alumno;
Ficha.Grupo := Grupo;
...
Archivar(Ficha);
end
else ...
end;
Como puede verse, he añadido una clase MotorReglaInscripcion. Esto está sujeto a debate. Si es posible que las reglas cambien, y que sean un tanto complejas o arbitrarias... me parece adecuado delegar en un motor de reglas que asuma esa responsabilidad y que el Procesador delegue parte del trabajo. Si esta etapa del trabajo (determinar si es válida) no cambia, pues que el método EsValidaInscripcion pertenezca a ProcesadorInscripcion y no exista el motor.
Muy posiblemente ProcesadorInscripcion tenga visibilidad de atributo del motor (si esta motivado su uso). Cabe la posibilidad de que este ProcesadorInscripcion haga poco trabajo, (¿sólo inscribe?) pero al menos deja clara la intención de que nos abstraemos de quien lleva a cabo formalmente la inscripción.
Se ha añadido el objeto FichaInscripcion. Este objeto a mi modo de ver, es quien en realidad termina siendo guardado o archivado (el que mejor convenga), leído y (¿actualizado?). Formalmente decimos que se llena una ficha o acta de inscripción y esto motiva la aparación de esta clase. Y si esta clase representa a dicho documento, es una buena candidata a ser quien termina conservando la información de que el estudiante a sido inscripto.
Puede que mi diseño sea un tanto, liviano... que hay muchas clases que hacen poco. Sólo hemos analizado una pequeña punta de un iceberg.
Podríamos seguir toda la semana con esto... a lo que quiero llegar es a una "simple" pregunta ¿Quién de nosotros tiene razón?
No hay, ni habrá, una única manera de representar un mismo problema. Disculpen nuevamente el rollo.
Saludos,