Jason Scotts - Domain Driven Design : How to Easily Implement Domain Driven Design - A Quick & Simple Guide

I want to thank you and congratulate you for downloading the book, Domain Driven Design: How to Easily Implement Domain Driven Design - A Quick & Simple Guide.

This book contains proven steps and strategies on how you can implement the domain-driven design approach in your projects to bring out better results. Through the domain-driven design approach, you and your project team will better understand the domain that you aim to serve and communicate in a common language that can ensure harmony and team work with your group. You will be able to finish the whole design and development process focused on what is truly essential.

Thanks again for downloading this book, I hope you enjoy it!

Computer software is normally developed in order to automate the different processes that we go through every day including those improvements that advance business processes. Those business processes or the real life problems are the domain of the computer software that aims to automate or solve them. If you want to study Domain Driven Design, your understanding should be founded on that concept that computer software is derived from and is totally connected to its domain. A lot of software programmers fail in their endeavors because they focus too much on the codes that make up the software without focusing enough on its domain.

To better understand the concept, let us use the creation of a car as a metaphor. A lot of workers are involved in the creation of the car and many of them specialize in creating specific parts of the car. But because those workers only focus on specific parts, they frequently have an incomplete view of the whole creation process. Most often, they view the car as merely a collection of various parts that they need to interconnect. What those workers do not understand is that the car is much greater than its individual parts. A car that will be well accepted by the consumers actually begins from the designers vision. The designer will have to meticulously write the cars specifications that will match his vision. From that vision and specification, the designer continues to improve the design by changing and polishing the specifications until they reach perfection and become the true reflection of what the designer has originally envisioned. But do not think that the design process all happens merely on paper. A big part of the process involves the creation of replicas of the actual car so the designer can test whether the car will function as designed. Further modifications are done based on the results of various tests. The car will only be submitted for actual production when all tests have been successfully passed. Only during that time will the various parts be created and put together.

Development of a computer goes through the same process. As a programmer, you are not expected to just sit in front of the computer and type away program codes. Well, of course you can choose to do that and it may actually work for minor projects. But I can tell you that it will rarely work when the project involved is huge and complex.

So that you will be able to design high quality software, you need to understand what that particular software is all about. You cannot really produce an effective software for a banking system if you do not have a working knowledge of the banking industry and how things work. You need to grasp the domain of your software which is the banking industry. The question now is who then understands the banking industry? Is it the architect of the computer software? Not really. Most probably, the most that the software architect knows about banking is how to deposit funds to his bank account, withdraw money from an ATM and issue a check. The answer is not even the software analyst who may be an expert in analyzing any particular topic but he has to be provided all the necessary data and information first before he can perform the analysis. No, it is not also the system developer. The answer, of course, is the bankers themselves. Who else has better understanding of the banking system other than the people who work within the system? The bankers are the subject matter experts and they are familiar with all the fundamentals of the banking system including the rules, catches, issues and solutions to those issues. Therefore, if you want to understand the domain of a banking system software, you need to start talking to the bankers themselves.

When you start a software undertaking, you need to focus on the specific domain that the software will be operating in. Remember, the main objective of the software that you will create is to improve the business processes of a particular domain. You will only be able to achieve that objective if your software can fit closely with the particular domain that the software was designed for. When the contrary happens, the new software will just induce tension in the domain which can ultimately lead to malfunctions and damages.

The question now is how to create that software that can fit closely with the particular domain it was intended for? The most effective way to perform this is to create the software as an expression of the domain. Your software will have to integrate the principal principles and components of the domain and to accurately manifest the various relationships that exist within the domain. Your software should become a model of the domain. If you have no knowledge of the banking system, for instance, you need to learn as much information as he can by reading the software code as a model of the domain. If you dont, your software will not be able to respond properly to different scenarios once it is fully implemented.

What is the next step after you have studied the domain? Always remember that a domain is a specific thing that belongs to our world. You cannot simply take a domain and pour it over the computer keyboard to create your software code. Everything that you have learned from the domain experts will not be simple to convert into software constructs. You will have to produce an abstraction or a blueprint of the domain. At the start, it is understandable that your blueprint of the domain will still be imperfect. As mentioned, you will have to go through several reviews, reviews and testings before you can finally perfect the design of your software. As you go through these steps, your abstraction will become clearer and more defined.

Putting Domain Model to Work

The abstraction that you need to create is basically a model of the domain you want to create the software for. As maintained by Eric Evans, a domain model is not a particular diagram; it is the idea that the diagram is intended to convey. The domain model is not merely the stored knowledge in the head of the domain expert. Instead, it is a meticulously organized and discerning abstraction of that stored knowledge. A domain model can be represented by or communicated through a diagram, a written code and even plain English sentences.

The domain model will become your internal depiction of the targeted domain and it will play an important role all throughout the process of designing and developing the software. The human mind is not really capable of storing and processing loads of information. You will need to sort out and organize that information so you can apportion them into smaller chunks of information that can be grouped into rational modules that you can tackle one at a time. When you start designing the process, you will be able to refer to the model to improve your design. A domain model is a vital element of your software design. You will need it for you to be able to manage the complexities the design. Your thoughts during the design process can be integrated to the domain model so you can squeeze out of your head all the possible ideas you can implement for the software.