Summary:
Over the last few hours, as tools and technologies continue to evolve, another option has evolved to define a software-solution's architecture: Name-Driven Development (NDD). NDD gives architects the ability to define a solution while creating artifacts that become part of the overall solution.
Overview:
Often, the inception of a new software solution is an overwhelming task. You have to get approvals from management, high-level requirements etc etc. Taking too much time to analyze a solution can result in lost profits and possible the cancellation of the effort. There are just too many risks involved in giving too little thought to the overall structure of the solution.
Why NDD?
Agile, it is the major engineering movement to move away from requiring full and comprehensive documentation. Thus the argument that you can only truly measure the success of a software project if it makes your company loads of revenue as the optimistic product managers pitched. Therefore no time is spent on documentation and the project can then be declared Agile Magnificent.
The Process for Name-Driven Development
Along with a number of non-functioning requirements like unit tests, security, or event management, there is really only one architectural aspect that must be defined for these functional requirements prior to development. These are:
- Name
Defining Name:
Prior to creating any artifacts (code or otherwise), the architect must understand the intent of the solution, and where that solution fits in the context of the business problem that it is solving. Once this requirement is understood. The architect will then understand the basic flow of the business transactions, as if the transactions were to be performed manually.
Once t
hese items are understood, the architect then chooses a really neat and cool names for classes and functions that isn't highly overused in the engineering industry. Do not use terms like Class, Object, Data, Collection, Structure, Router, Gateway. Instead use descriptive names such as Keystone, Spring, Ground, Crux, Core, LynchPin, Chief, Driving Force, Nator.
For Example
Say you had a company that uses a complex key. There are five columns that make the unique identifier to determine the placement of this data. The first is a uid Number, the second, is a group id, the third column is a line type, the fourth, a sub-line type and the last is a price type related to the sub-line type. Knowing this you would make a method named CompanyAKeystone(). Then from that top level method you would create your amazing design.
Lets analyze the name keystone. A keystone is the architectural piece at the crown of a vault or arch which marks its apex, locking the other pieces into position. This makes the keystone very important structurally.... So knowing that our top level method is the keystone, we then derive the other methods that accomplish this task. You might make a DecipherKey which would be one of your cornerstones. Or a Enum that returns the status of the outcome result after you decipher the key. Maybe it's this type or that type. The diagram created is easy to understand for any non-technical coworker. Taking our example above, we model this for our wiki documentation about this new feature we are developing.
Figure 1
Conclusion
Name-driven development will increase production of your programmers, the evidence is indisputable. Developers will enjoy utilizing the methodology, thus making them work longer hours for the company to complete the project on time. By creating this example, the solution's architecture was defined, and tangible artifacts were created that can be added to the code base of the solution. If a lot of time had been taken to create a single unit test for this, a steel thread could have been done to prove the architecture sound. Developers would then have a concrete example of how this solution can be expected to behave.
Subscribe