p { margin-bottom: 0.1in; line-height: 120%; }
Para mi método, eso es probablemente lo más importante en la arquitectura y el diseño de software.
- Cuando se va a escribir una solución de software, hay que distinguir entre dos dominios: el dominio del problema y el dominio de la solución
Los clientes, el mundo, el negocio, a través del equipo de producto van dando forma o construyendo el dominio del problema, mientras que los buenos arquitectos de software, se encargan del diseño del dominio de la solución, que incluye los constructos, conceptos y tecnología mediante los cuales se implementará la solución
- El dominio del problema y el dominio de la solución se describen utilizando modelos y conceptos.
Los conceptos, y especialmente los diferentes elementos del modelo (entidades, relaciones, comportamientos, procesos) es lo que se materializaría como elementos de software.
Una incoherencia en la definición de los conceptos dará lugar a un modelo roto - un fallo lógico que en un momento u otro:
- Causar un error (normalmente unos cuantos) - ya sea un pequeño error, como una pequeña pieza de funcionalidad que no funciona bien, o uno serio
Causar que la solución no sea una solución - es decir, que no se ajuste al dominio del problema
A menudo verás a arquitectos o desarrolladores experimentados discutiendo sobre el nombre de un componente de software. Puede parecer absurdo para un espectador, pero está lejos de serlo, porque mientras discuten sobre la denominación, lo más profundo que ocurre en sus cabezas es el refinamiento de los conceptos relacionados con ese artefacto de software y otros elementos del modelo asociados a él. A menudo se trata de definir claramente la responsabilidad de las diferentes entidades y procesos, etc. del modelo, sin demasiadas zonas grises y, desde luego, sin definiciones contradictorias ni piezas perdidas. - En otras palabras - están trabajando en la integridad conceptual del diseño.