I have spent the past several days learning about domain driven design and attempting to apply it to a current project. I decomposed the problem domain into the canonical logical components: domain, infrastrucutre, and presentation. Having completed a first pass, I stepped back and realized that the architecture I created resulted in virtually all of the business logic being contained in the application services, which is the tell-tale sign of the anemic domain model code smell. After further consideration, domain driven design may not be the correct fit for my application, and even if it is, given the small number of business logic rules in my application, the layering overhead may not be worth it. Since I have only written UML and psuedo code I haven't invested too much time and effort, but I would like to leverage what I can if it's possible.
My architecture consists of 4 physical components:
- The "domain" project: abstractions and CRUD methods for the data type I use
- The "infrastucture" project: the logical representation and methods to be performed on the data
- The "presentation" project: the user interface (WinForms or WPF)
- The "services" project: coordiates the domain and infrastucture objects according to business rules
If I were to use the components as designed in a multitiered architecture, my presentation layer would only hold references to 3 or 4 services to handle all application functionality. Is this a valid approach?