Understanding Domain Driven Design
When I have some free time, I look into the other ways to build software. By doing this, it helps me to expacd my existing knowledge and understand newer and better ways of doing the same thing. One of the ways that I have ran across was doing Domain Driven Design. This design pattern is much different than what I am used to doing, especially in my current role.
After researching it many of times, it did not make sense. Eventually I did find some tutorials on YouTube that broke it down into terms that I could understand. Below is a breakdown of my understanding of what I believe that Domain Driven Design is.
Larger Picture
One that I have found to be common across the board is the diagrams that people have created describing how the application should be structure. It resembles the below.
API (or UI or Front End) -> Application -> Domain
Infrastructure -> Application -> Domain
In short, the outer layers reference the inner layers. None of the inner layers point to the outer layers. The inner layers do have interfaces that are utilized by the outer layers, which results in the application functionality. This is commonly referred to as Onion Architecture.
Domain
This is the core of the application. This part of the application contains the business rules as well as the entities that make up the application.
One thing that I am noticing about this aspect of the architecture is that there are a number of ways that people do things. I saw one that would not throw exceptions from the constructor. Instead he would create his entities with a Create method that accepts the required arguments. If those arguments violated any of the business rules, the exception would be thrown from the Create method instead of the constructor.
Another thing that I have observed is that some create a file for each class, exception, value object, and other aspects of the domain. Whereas some combine some of these items together into a single file when they are related to each other. In my opinion, this indicates that there is no standard or convention for doing this, thus it is up to the developer to do what s/he chooses.
Anemic Domain Model
This is a term that I have seen a lot when DDD is mentioned. Of course when trying to understand things that I do not know, I do my research on them so that I can know more about them. I then found out that anemic domain model basically means that the domain does not have any business logic contained in it. In this scenario, the logic or business rules are typically placed into the Service layer of the application.
Application
This is where the business logic is combined and grouped into "use cases". Use cases are things that occur with your application, such as purchasing an order, creating an user, or editing a product.
How I understand it, "handlers" are created for each of these use cases. The handler calls a series of methods that are defined in the domain to perform an action. Also the Application layer has interfacing services to perform additional actions, such as calling an email service to send a notification to a user when they have requested their password to be reset.
Another article that I read on Martin Fowler's website mentioned that the Application layer is the equivalent to the Service layer in other architecture patterns. This brought greater clarity to me because I am familiar with having a Service layer in my applications.
Infrastructure
This is where the database (or repository) and other external (non code) portions of the application will have their implementation included. The reason that this is done in a separate layer is so that the domain can be tested without any of the infrastructure in place.
This is far different from the MVC or typcial architecture that I am used to working with. In my current role, we have the database as the center of the application and then everything else, including presentation, business logic, and more are dependent upon that. Problem with doing things in this manner is that you have to have a database, whether in memory or SQL server, created and running in order to test the application, which can be a problem.
Conclusion
In Terms I Understand
After reading mutliple perspectives of the pattern or style, it makes more sense to me now. The larger view looks like this...
API (or UI or Front End) -> Services Layer -> Domain Layer
Infrastructure (DB, external services) -> Services Layer -> Domain Layer
The problem that I think I had was DDD design uses certain terms that I was not familar with to describe the layers. The reading of articles that others have wrote and watching tutorials, helped bridge the gap.
Applying the Knowledge
I will be applying this knowledge going forward to the personal applications that I have created. I am planning to do refactoring of the Falcon Pi Twitter application and some of the others that I actively use in the future. I will probably do a coding series on the refactoring, so stay tuned to the YouTube channel for that.
Conclusion
I have several projects that I want to refactor to this new architecture pattern. Thing the first that I will do this way, will be the application that I have created that posts the weather information to this blog in the Lifestyle section of this website. Then after that will refactor the Falcon Pi Twitter project to the new pattern.