With the advent of agile development methodologies, many of their edicts have been filtering back to the design stages in the form of what is now called "Domain Driven Design" (DDD). Concepts like group brainstorming design sessions, on-site customers and iterative development have had a dramatic affect on the realm of software architecture.
The days of the "waterfall" mentality are dwindling, people are looking for a fresh new approach to software development and with just reason. Business is an organic entity, ever changing and evolving to meet the needs of its market but the software it uses is often limited because it only meets the business' current needs. The process by which it was developed is flawed, people spout promises of extensibility but I'm not sure we are all on the same page when it comes to the definition of that word.
With waterfall, the Subject Matter Experts (SME's) talk to the analysts, who, in turn, create a multitude of charts and diagrams representing the business process in a more abstracted "technical" language for the developers. The problem with this model is the singular direction in which information travels. The SME's and the analyst learn nothing from the development staff. As well, the information that filters from the SME's to the development staff minimizes their exposure to and understanding of the business. When your development staff does not understand the business, there effectiveness is altered and their tasks become features instead of principles.
Agile is not immune to this dilemma. Development teams get so caught up in the feature list for a given iteration, they become nothing more than an feature assembly line, only pausing long enough to ask, "What's next?"
Feature, rather than principle driven software, can be robust; particularly if the development team practices refactoring, but it will rarely benefit from a system developed with the understanding of the business. Subtle decisions made in the design process can be the difference between a system of rich domain objects and anemic ones
Developing a robust, domain driven model is a bit of an art, but the practical design and implementation is relatively systematic. By isolating the domain from the mass of concerns in the implementation of the system will greatly enhance the connection between the domain and the software derived from it. Definition of model elements from the domain will sharpen their meaning and provides for a more practical design implementation.
The days of the "waterfall" mentality are dwindling, people are looking for a fresh new approach to software development and with just reason. Business is an organic entity, ever changing and evolving to meet the needs of its market but the software it uses is often limited because it only meets the business' current needs. The process by which it was developed is flawed, people spout promises of extensibility but I'm not sure we are all on the same page when it comes to the definition of that word.
With waterfall, the Subject Matter Experts (SME's) talk to the analysts, who, in turn, create a multitude of charts and diagrams representing the business process in a more abstracted "technical" language for the developers. The problem with this model is the singular direction in which information travels. The SME's and the analyst learn nothing from the development staff. As well, the information that filters from the SME's to the development staff minimizes their exposure to and understanding of the business. When your development staff does not understand the business, there effectiveness is altered and their tasks become features instead of principles.
Agile is not immune to this dilemma. Development teams get so caught up in the feature list for a given iteration, they become nothing more than an feature assembly line, only pausing long enough to ask, "What's next?"
Feature, rather than principle driven software, can be robust; particularly if the development team practices refactoring, but it will rarely benefit from a system developed with the understanding of the business. Subtle decisions made in the design process can be the difference between a system of rich domain objects and anemic ones
Developing a robust, domain driven model is a bit of an art, but the practical design and implementation is relatively systematic. By isolating the domain from the mass of concerns in the implementation of the system will greatly enhance the connection between the domain and the software derived from it. Definition of model elements from the domain will sharpen their meaning and provides for a more practical design implementation.
No comments:
Post a Comment