Got this in an email. for those of you who work in XML, its funny.
10. WS-IrishSpring: for scented, more pleasing SOAP packets
9. WS-UPS: for sending SOAP packets in real envelopes
8. WS-USPS: for sending SOAP packets that dont need to get there
7. WS-PrisonShower: for picking up the dropped SOAP packets
6. X-Wife: protocol for monetary transfer
5. WS-Insecurity: dating protocol for web services programmers
4. WS-Monopoly: protocol used to keep antitrust penalties to manageable levels
3. NICKLE: for encoding smaller binary attachments
2. SFFCI: Syndication Format for Complete Idiots
1. WS-XXX: bringing a business model to XML.
2/20/2007
Domain Driven Design
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.
It's Like Riding a Bicycle?
I have been struggling these past few days to "define" a concept I have been doing for the past 4 years, a "Domain Pattern". It really is more that a software pattern, its an entire process pattern for designing and developing software.
I never realized how difficult it can be to try and impart "inate" knowledge to others; It is turning out to be a fairly difficult task. It is one I liken to trying to explain to someone how to ride a 2 wheel bicycle. How do you explain balance?
True, you can convey certain concepts with words, but the actual development of balance must be learned through trial and error.
I think I need a mental rosetta stone...
I never realized how difficult it can be to try and impart "inate" knowledge to others; It is turning out to be a fairly difficult task. It is one I liken to trying to explain to someone how to ride a 2 wheel bicycle. How do you explain balance?
True, you can convey certain concepts with words, but the actual development of balance must be learned through trial and error.
I think I need a mental rosetta stone...
Subscribe to:
Posts (Atom)