DDD: Chapters 1 - 3
The first 3 chapters of Domain Driven Design (DDD) focuses on the critical ingredients that are necessary in producing a productive software architectural model. It discusses the importance of knowledge crunching, establishing an ubiquitous language and using the application model as basis for further development.
Knowledge crunching is very key in a team-development project that involves technical and non-technical participants. As is often the case, a group of technical developers are given the task of translating business requirements (from stakeholders) into a feasible technical solution, which makes understanding the requirements very key to the success of the project. Eric Evans emphasizes in his book DDD that key to bridging this knowledge gap is knowledge crunching which involves a healthy interaction between the development team and the subject matter experts (SME). During this process, the architect walks through various scenarios with the SME, a process that naturally starts to generate leading questions and helps generate a deeper understanding of subject. This step of interacting with the SME, to help develop a better understanding of the business rules, is a crucial art that an architect must develop. It also helps if the architect is able to use diagrams (eg. UML) to illustrate the various scenarios, but the most important part of this interaction is communication as Evans refers to as establishing a ubiquitous language.
The ubiquitos language discussed is the set of terminologies that is defined by the parties involved, and is well understood by all parties. It comprises of those technical terms that the SMEs have to familiarize themselves with as well as those business terms that the developers have to capture. A word like "code" is used so commonly, and yet could mean many different things to different people; thus, specifically nailing down the meaning of the the word would save several hours of wrong programming.
With an established ubiquitous language, the team can now translate the business requirements to a model and then to an implementation. Evans establishes the importance of tightly coupling the model to the implementation. In short, a hands-on architect is priceless to the consistency of a development cycle--yielding a software product that correlates with the design model.
Knowledge crunching is very key in a team-development project that involves technical and non-technical participants. As is often the case, a group of technical developers are given the task of translating business requirements (from stakeholders) into a feasible technical solution, which makes understanding the requirements very key to the success of the project. Eric Evans emphasizes in his book DDD that key to bridging this knowledge gap is knowledge crunching which involves a healthy interaction between the development team and the subject matter experts (SME). During this process, the architect walks through various scenarios with the SME, a process that naturally starts to generate leading questions and helps generate a deeper understanding of subject. This step of interacting with the SME, to help develop a better understanding of the business rules, is a crucial art that an architect must develop. It also helps if the architect is able to use diagrams (eg. UML) to illustrate the various scenarios, but the most important part of this interaction is communication as Evans refers to as establishing a ubiquitous language.
The ubiquitos language discussed is the set of terminologies that is defined by the parties involved, and is well understood by all parties. It comprises of those technical terms that the SMEs have to familiarize themselves with as well as those business terms that the developers have to capture. A word like "code" is used so commonly, and yet could mean many different things to different people; thus, specifically nailing down the meaning of the the word would save several hours of wrong programming.
With an established ubiquitous language, the team can now translate the business requirements to a model and then to an implementation. Evans establishes the importance of tightly coupling the model to the implementation. In short, a hands-on architect is priceless to the consistency of a development cycle--yielding a software product that correlates with the design model.
posted by Toniez alamo de la mite at
5:08 PM
0 Comments:
Post a Comment
<< Home