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?
I think that you are on the right track but it might be easier to understand possible different nomenclature to get a better understanding about the role that each of the layers will play in the architecture.
The Martin Fowler article that you linked where he coined the term, Anemic Data Model was his criticism at the time for transactional based architecture and the trend to push Behavior out of data objects entirely. Being a staunch believer in OOP programming and design it is a valid criticism, as he worries about the sophistication of software devolving back to the days of structs and procedural programming. Personally I feel he is rather alarmist and this will not be a problem if strict architectural adherence to layerd and tiered software design is followed in a stateless and transactional way.
-
Domain layer consists of data objects that have the knowledge and ability to persist themselves to database or file
-
Infrastructure layer This could also be known as your Data Access Layer. Stateless DAO classes will have the ability to fetch data objects.
-
I propose you have a seperate Business Logic Layer. Any and all application logic, special domain logic, interactions with multiple DAO or external web services, integrating third party services to satisfy business rules and all in a stateless transactional way, are all examples of what code belongs here. Sure some of this will simply be a wrapper to a single DAO call, but the seperation of concerns and low coupling is the benefit.
-
Presentation Layers There can be multiple presentation layers but they will typically be the arbiters of stateful communication with your users. A good example of this would be the Controller in MVC architecture. It can maintain stateful interaction, and where business logic operations are required, it should be as simple as calling the necessary transactions to retrieve the data needed or perform the necessary operation. There are different types of presentation as well, a thick client or web server will can call the business logic layer directly, or perhaps the business logic can be wrapped by web services that return the data in a useful form.
-
Service Layers The service layer should be devoid of any application or business logic and should focus primarily on a few concerns. It should wrap Business Layer calls, translate your Domain in a common language that your clients can understand, and handle the communication medium between server and requesting client.
Knowing this and understanding the benefits of why this type of transactional architecture might be useful to you however depend entirely on the type of software that you are building. Also questions about the appropriate number of services are meaningless in this case without a complete understanding of your business and technical requirements. It is a valid approach if you wish to build large highly maintainable, scalable solutions with low coupling. If you are building a smaller application with few business concerns or objectives then perhaps it is overkill.
3