Recently, while having a discussion with a group of colleagues that are new to the Domain Driven Design (DDD) approach, some points highlighted by these colleagues truly reflect how I first felt when I tried to understand the approach from the book and applying it. Probably for anyone new to this and like to apply the DDD, the whole approach can be sub divided into a few areas to provide a better segregation of understanding and implementation.
Understanding the concept
I will say that it is not that difficult to understand the concept from reading the book. The first part of the book with the first three chapters well describes the concept. This concept covers mainly the design approach with DDD. Personally, I think the concept is powerful, clean and easy to understand and use to drive most design. With part 1 of the video by Eric Evan on InfoQ a better picture can be provided straight from the horse’s mouth. Having a good understand of the concept is important before moving into the implementation.
Driving the Design
Modeling is the main utility in the DDD. The concept used, clearly defined how to design the model and how everyone within the project use the model as the backbone for discussion to the actual implementation in codes. This clearly reflects back to the concept of DDD. One important factor during the design is not to add other complexity such as infrastructure into the design and the domain model. So far, there wasn't much problem with the adoption of this approach during the design phase and the domain model really provide the team with a solid backbone from the design to the implementation.
Implementation of the Design into Codes
If you have noticed, I have not said much of the concept and driving the design much above, as I believe what is mentioned in the DDD book is more than enough to give you a good start. However do note the following remarks found in chapter 3 of the book:
Understanding the concept
I will say that it is not that difficult to understand the concept from reading the book. The first part of the book with the first three chapters well describes the concept. This concept covers mainly the design approach with DDD. Personally, I think the concept is powerful, clean and easy to understand and use to drive most design. With part 1 of the video by Eric Evan on InfoQ a better picture can be provided straight from the horse’s mouth. Having a good understand of the concept is important before moving into the implementation.
Driving the Design
Modeling is the main utility in the DDD. The concept used, clearly defined how to design the model and how everyone within the project use the model as the backbone for discussion to the actual implementation in codes. This clearly reflects back to the concept of DDD. One important factor during the design is not to add other complexity such as infrastructure into the design and the domain model. So far, there wasn't much problem with the adoption of this approach during the design phase and the domain model really provide the team with a solid backbone from the design to the implementation.
Implementation of the Design into Codes
If you have noticed, I have not said much of the concept and driving the design much above, as I believe what is mentioned in the DDD book is more than enough to give you a good start. However do note the following remarks found in chapter 3 of the book:
Developing a single model that captures the problem and provides a practical design is easier said than done. You can't just take any model and turn it into a workable design. The model has to be carefully crafted to make for a practical implementation. Design and implementation techniques have to be employed that allow code to express a model effectively. Knowledge crunchers explore model options and refine them into practical software elements. Development becomes an iterative process of refining the model, the design, and the code as a single activity.
To me, the actual complexity of the whole DDD approach is in the implementation of the design into codes. This is the greatest barrier I had when I first tried to transfer the design into codes. In part two of the DDD book, certain design patterns are mentioned on how the design or model can be implemented into codes, however I find these part can be greatly improve on. Even after reading the Applying Domain Driven Design and Patterns with Examples in C# and .Net by Jimmy Nilsson does not help much. Not trying to say that the book is not good, but just probably not enough to transits from the design into codes.
Phillip Calcado has written an article on Repository Trouble and I believe this is another example of how much certain doubts on the implementation are not clearly explained and probably due to the lack of example. From my understanding, the main responsibility of the repository as mentioned in the book:
Phillip Calcado has written an article on Repository Trouble and I believe this is another example of how much certain doubts on the implementation are not clearly explained and probably due to the lack of example. From my understanding, the main responsibility of the repository as mentioned in the book:
Hide all the inner workings from the client, so that client code will be the same whether the data is stored in an object database, stored in a relational database, or simply held in memory. The repository will delegate to the appropriate infrastructure services to get the job done.
Example
In a domain with a user object, this user will probably have a few implementation methods such as create user, inactive user, get user information and many others... Each method will need to persist or retrieve the user object, but each method should not be aware of where this information is persisting thru DAO or LDAP or even file. The repository should take care of this responsibility and in return hiding the persistence and the infrastructure from the domain layer. Without this repository, each method will be required to know where to persist each object.
Other than what is mentioned, the repository also help to enforce certain domain logic such as preventing queries from pulling exact data rather than navigating from aggregate roots.
Will continue to discuss more on the DDD implementation in subsequent post...
Additional videos by Eric Evans
Part 2: Strategic Design
Part 3: Domain-Driven Design and Domain Specific Languages
Additional videos by Eric Evans
Part 2: Strategic Design
Part 3: Domain-Driven Design and Domain Specific Languages
No comments:
Post a Comment