Elevate Developer Efficiency & build GenAI Application with Amazon Qâ
Â
Domain Driven Design
1. Domain Driven Design With Entity Framework 4.0 Presented By: Muhammad Moussa Mohamed R. Samy 1
2. Agenda What is Domain Driven Design? Layered architecture in Domain-Driven Design Developer & Domain Expert Show Domain Driven Design building blocks at glance Building Domain Model with EF 4.0 Model First Building Domain Repositories with EF 4.0 Building Domain Services Verifying domain with Unit Tests 2
4. Agenda What is Domain Driven Design? Layered architecture in Domain-Driven Design Developer & Domain Expert Show Domain Driven Design building blocks at glance Building Domain Model with EF 4.0 Model First Building Domain Repositories with EF 4.0 Building Domain Services Verifying domain with Unit Tests 4
6. Agenda What is Domain Driven Design? Layered architecture in Domain-Driven Design Developer & Domain Expert Show Domain Driven Design building blocks at glance Building Domain Model with EF 4.0 Model First Building Domain Repositories with EF 4.0 Building Domain Services Verifying domain with Unit Tests 6
8. Agenda What is Domain Driven Design? Layered architecture in Domain-Driven Design Developer & Domain Expert Show Domain Driven Design building blocks at glance Building Domain Model with EF 4.0 Model First Building Domain Repositories with EF 4.0 Building Domain Services Verifying domain with Unit Tests 8
10. Agenda What is Domain Driven Design? Layered architecture in Domain-Driven Design Developer & Domain Expert Show Domain Driven Design building blocks at glance Building Domain Model with EF 4.0 Model First Building Domain Repositories with EF 4.0 Building Domain Services Verifying domain with Unit Tests 10
12. Agenda What is Domain Driven Design? Layered architecture in Domain-Driven Design Developer & Domain Expert Show Domain Driven Design building blocks at glance Building Domain Model with EF 4.0 Model First Building Domain Repositories with EF 4.0 Building Domain Services Verifying domain with Unit Tests 12
14. Agenda What is Domain Driven Design? Layered architecture in Domain-Driven Design Developer & Domain Expert Show Domain Driven Design building blocks at glance Building Domain Model with EF 4.0 Model First Building Domain Repositories with EF 4.0 Building Domain Services Verifying domain with Unit Tests 14
16. Agenda What is Domain Driven Design? Layered architecture in Domain-Driven Design Developer & Domain Expert Show Domain Driven Design building blocks at glance Building Domain Model with EF 4.0 Model First Building Domain Repositories with EF 4.0 Building Domain Services Verifying domain with Unit Tests 16
Reference:http://ajlopez.wordpress.com/2008/09/12/layered-architecture-in-domain-driven-design/Evans writes:For a shipping application to support the simple user act of selecting a cargoâs destination from a list of cities, there must be program code that (1) draws a widget on the screen, (2) queries the database for all the possible cities, (3) interprets the userâs input and validates it, (4) associates the selected city with the cargo, and (5) commits the change to the database. All of this code is part of the same program, but only a little of it is related to the business of shipping.He proposes that the domain model resides in a layer, the Domain Layer. In this way, the domain model is protected from technicalities as concrete persistence implementation, and presentation duties. I like to say that the domain is as an organism, that receives stimula, actions from the outside, and reacts to such commands. The domain should run without detailed knowledge of the rest of the application. Serialization between physical tiers, presentation details and database access, should be clearly separated from the domain implementation.The layers could be described as:UI (User Interface): the easiest to understand, this layer is the responsible of displaying information to the user, and accept new data. It could be implemented for web, desktop, or any presentation technology, present or future. For example, it could be a voice application, that interacts with the user via a phone. The acid test for our design is that a radical change in user interface should have minimal (or controled, at least) impact in the rest of the system.Application Layer: itâs in charge of coordinating the actions to be performed on the domain. There are no business rules or domain knowledge here. No business state resides in this layer. It delegates all domain actions to the domain. It could coordinate many actions (possibly in many domains). It could prepare the infrastructure to be ready to work with the domain for an specific action (for example, preparing transaction scopes).Domain Layer: In this layer resides the heart of software, according to Evans. Business rules and logic lives inside this layer. Business entity state and behavior is defined and used here. Communication with other systems, persistence details, are forwarded to the infrastructure layer. Evans discuss the patterns he uses in this layer, as Entities, Value Objects, Services, Repositories and Factories. We would explore the patterns and implementations in future posts.Infrastructure Layer: God and devil are in the details, and in the infrastructure layer. Its main responsibility is the persistence of the business state, most frequently, using a relational database.
