ddd
TRANSCRIPT
![Page 1: DDD](https://reader037.vdocuments.mx/reader037/viewer/2022110306/554f3676b4c90572088b4c50/html5/thumbnails/1.jpg)
Antonio Radesca
http://dotnetslackers.com/Community/blogs/antrad/
Domain Driven Design
![Page 2: DDD](https://reader037.vdocuments.mx/reader037/viewer/2022110306/554f3676b4c90572088b4c50/html5/thumbnails/2.jpg)
•Business Requirement <>Business Modeling<>Software Design
Business Modeling Software Design
OrderCustom
er
Product
1..*
Domain Model
Process
(text)
Business Requirement
![Page 3: DDD](https://reader037.vdocuments.mx/reader037/viewer/2022110306/554f3676b4c90572088b4c50/html5/thumbnails/3.jpg)
![Page 4: DDD](https://reader037.vdocuments.mx/reader037/viewer/2022110306/554f3676b4c90572088b4c50/html5/thumbnails/4.jpg)
•DDD is a set of mindset,principles and practices for support software design related to complex domains•We must use DDD because software implementation is often very different from its initial description•DDD try to link model and design ever•Formalized by Eric Evans in “Domain Driven Design: Tackling Complexity In The Heart Of Software”
![Page 5: DDD](https://reader037.vdocuments.mx/reader037/viewer/2022110306/554f3676b4c90572088b4c50/html5/thumbnails/5.jpg)
•Software development is knowledge of the subject matter•Software is different from analisys model•Some information is not expressed •Analisys model fails because crucial discoveries emerge during design/coding effort
![Page 6: DDD](https://reader037.vdocuments.mx/reader037/viewer/2022110306/554f3676b4c90572088b4c50/html5/thumbnails/6.jpg)
•Ubiquitous Language•Design practices and patterns
![Page 7: DDD](https://reader037.vdocuments.mx/reader037/viewer/2022110306/554f3676b4c90572088b4c50/html5/thumbnails/7.jpg)
•Model is a set od concepts expressed as words and relations used for improve comunications between stakeholders•Jargon domain experts<> Jargon developers•DM provides language for communication between domain experts and developers•Terms of UL come from DM•Ubiquitous language force finding common problems in problem resolution•Use DM as backbone of language•UL must be used in speechs and diagrams too
![Page 8: DDD](https://reader037.vdocuments.mx/reader037/viewer/2022110306/554f3676b4c90572088b4c50/html5/thumbnails/8.jpg)
•Changes to UL are changes to DM•DM with UL is a design artifact and is shared from domain experts and developers•Describing scenarios is the best practice•Recognizing problems is more simple
![Page 9: DDD](https://reader037.vdocuments.mx/reader037/viewer/2022110306/554f3676b4c90572088b4c50/html5/thumbnails/9.jpg)
•UML is very good but fails in some things•Object diagram shows attibutes and relationship very good but there are not so much information about behaviour of components•We can use sequence diagram but text and conversations are the most powerfull instruments•UML fails in:meaning of concepts it represents (states) and what the objects are meant to do.
•COMMUNICATION BASED ON UL AND MODEL
Ubiquitous language and Documentation
![Page 10: DDD](https://reader037.vdocuments.mx/reader037/viewer/2022110306/554f3676b4c90572088b4c50/html5/thumbnails/10.jpg)
•A document shouldn’t try to do what the code already does well•Documents must explane concepts of model•Help in navigating code•UL helps documents •Concise and less amiguous•Requirements become scenarios
DDD, documents and diagrams
![Page 11: DDD](https://reader037.vdocuments.mx/reader037/viewer/2022110306/554f3676b4c90572088b4c50/html5/thumbnails/11.jpg)
•Diagrams are a means of communication and explanation•They serve these ends if they are minimal•They represent the skeletons of ideas•Model<>Diagram•Diagram communicate and explane model•Documents and diagrams must complement code and speechs
•The vital details are capturated into CODE!
![Page 12: DDD](https://reader037.vdocuments.mx/reader037/viewer/2022110306/554f3676b4c90572088b4c50/html5/thumbnails/12.jpg)
CargocargoIdorigindestination
Routing service
OriginDestination Populate
CargoDB table:cargo_booking
Cargo_Id,Transport,Load,Unload
![Page 13: DDD](https://reader037.vdocuments.mx/reader037/viewer/2022110306/554f3676b4c90572088b4c50/html5/thumbnails/13.jpg)
Routing Service
A Route Specification
An Itinerary satisfytingthe Route specification
![Page 14: DDD](https://reader037.vdocuments.mx/reader037/viewer/2022110306/554f3676b4c90572088b4c50/html5/thumbnails/14.jpg)
![Page 15: DDD](https://reader037.vdocuments.mx/reader037/viewer/2022110306/554f3676b4c90572088b4c50/html5/thumbnails/15.jpg)
•MDD support DDD•Structure software around some set of concepts•Example:UI Framework is developed as UI concepts (menu,windows for example) and corrisponds to actual software construct•Design <>Model=Software not correct•MDD discard Analisys Model•Mapping between model and design
![Page 16: DDD](https://reader037.vdocuments.mx/reader037/viewer/2022110306/554f3676b4c90572088b4c50/html5/thumbnails/16.jpg)
•Modeling and design will be a single iterative loop•Model is revisited to be implemented more naturally in software•Code will be an expression of model•Correspondence will be literal•This is more effective using OOP
![Page 17: DDD](https://reader037.vdocuments.mx/reader037/viewer/2022110306/554f3676b4c90572088b4c50/html5/thumbnails/17.jpg)
LayeringUser Interface (Presentation Layer)Responsible for presenting information to the user andinterpreting user commands.
Application LayerThis is a thin layer which coordinates the applicationactivity. It does not contain business logic. It does nothold the state of the business objects, but it can holdthe state of an application task progress.
Domain Layer This layer contains information about the domain. Thisis the heart of the business software. The state ofbusiness objects is held here. Persistence of thebusiness objects and possibly their state is delegated tothe infrastructure layer.
Infrastructure LayerThis layer acts as a supporting library for all the otherlayers. It provides communication between layers,implements persistence for business objects, containssupporting libraries for the user interface layer, etc.
![Page 18: DDD](https://reader037.vdocuments.mx/reader037/viewer/2022110306/554f3676b4c90572088b4c50/html5/thumbnails/18.jpg)
•Entity•Value Object•Service•Repository•Aggregates•Factory
![Page 19: DDD](https://reader037.vdocuments.mx/reader037/viewer/2022110306/554f3676b4c90572088b4c50/html5/thumbnails/19.jpg)
![Page 20: DDD](https://reader037.vdocuments.mx/reader037/viewer/2022110306/554f3676b4c90572088b4c50/html5/thumbnails/20.jpg)
Defines an application's boundary with a layer of services that establishes a set of available operations and coordinates the application's response in each operation.
A service typically implements a business rule, generally something that software must do.
Infrastructure and domain logic services
A Service Layer defines an application's boundary [Cockburn PloP] and its set of available operations from the perspective of interfacing client layers. It encapsulates the application's business logic, controlling transactions and coor-dinating responses in the implementation of its operations.
![Page 21: DDD](https://reader037.vdocuments.mx/reader037/viewer/2022110306/554f3676b4c90572088b4c50/html5/thumbnails/21.jpg)
![Page 22: DDD](https://reader037.vdocuments.mx/reader037/viewer/2022110306/554f3676b4c90572088b4c50/html5/thumbnails/22.jpg)
Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects.
A Repository encapsulates the set of objects persisted in a data store and the operations performed over them, providing a more object-oriented view of the persistence layer. Repository also supports the objective of achieving a clean separation and one-way dependency between the domain and data mapping layers.
![Page 23: DDD](https://reader037.vdocuments.mx/reader037/viewer/2022110306/554f3676b4c90572088b4c50/html5/thumbnails/23.jpg)
![Page 24: DDD](https://reader037.vdocuments.mx/reader037/viewer/2022110306/554f3676b4c90572088b4c50/html5/thumbnails/24.jpg)
•Aggregate is a cluster of associated objects that we treat as a unit for the purpose of data changes.•Each aggregate has a root and a boundary
![Page 25: DDD](https://reader037.vdocuments.mx/reader037/viewer/2022110306/554f3676b4c90572088b4c50/html5/thumbnails/25.jpg)
Creates and manage complex objects.
Abstract Factory Provides an interface for creating families of related or dependent projects without specifying their concrete classes.
![Page 26: DDD](https://reader037.vdocuments.mx/reader037/viewer/2022110306/554f3676b4c90572088b4c50/html5/thumbnails/26.jpg)
•A good design helps to mantain project in consistent state and integrity model.
![Page 27: DDD](https://reader037.vdocuments.mx/reader037/viewer/2022110306/554f3676b4c90572088b4c50/html5/thumbnails/27.jpg)
•Bounded Context delimits the applicability of a particular model.•Sets boundaries of team organization,usage of specific parts of application and physical (code,db,etc)
![Page 28: DDD](https://reader037.vdocuments.mx/reader037/viewer/2022110306/554f3676b4c90572088b4c50/html5/thumbnails/28.jpg)
Next time….:D
![Page 29: DDD](https://reader037.vdocuments.mx/reader037/viewer/2022110306/554f3676b4c90572088b4c50/html5/thumbnails/29.jpg)
•Describe the points of contact between the models…•Express models relationship•Overlap between project management and software design•Helps communication between teams•UL by different teams must be shared
•Map the existing terrain.Take up trasformations later.
![Page 30: DDD](https://reader037.vdocuments.mx/reader037/viewer/2022110306/554f3676b4c90572088b4c50/html5/thumbnails/30.jpg)
•Part of the system that is shared from 2 or more teams•Part of the system that cannot be changed freely as other parts of the system•Decisions involve consultation with an another team•Automatic tests must be integrated by teams
![Page 31: DDD](https://reader037.vdocuments.mx/reader037/viewer/2022110306/554f3676b4c90572088b4c50/html5/thumbnails/31.jpg)
•Large systems have many interfaces with others•An isolation layer talks to others throught its existing interface requiring little or no modifications to other systems•It is not a system for send messages•It is a mechanism that translates conceptual objects and actions from one model and protocol to an other•Sometimes is a complex part of a software•Often is designed as a set of services•Use some patterns (FACADE,Adapter)
![Page 32: DDD](https://reader037.vdocuments.mx/reader037/viewer/2022110306/554f3676b4c90572088b4c50/html5/thumbnails/32.jpg)
A little bit…. :D
![Page 33: DDD](https://reader037.vdocuments.mx/reader037/viewer/2022110306/554f3676b4c90572088b4c50/html5/thumbnails/33.jpg)
ORMSOAPatternsRefactoring TDDIOC
![Page 34: DDD](https://reader037.vdocuments.mx/reader037/viewer/2022110306/554f3676b4c90572088b4c50/html5/thumbnails/34.jpg)
ClientsI DClient
NameSurname
Address
City
I nvoicesI D
DateI nvoice
Total
ClientI d
I nvoiceDetailsI nvoiceI d
Product
Row Total
UnitPrice
ClientC la s s
F ield s
Pro p erties
Ad d ressCity
I DN ameSurname
I nvoiceC la s s
F ield s
Pro p erties
D ateI nvo iceI D
To tal
I nvoiceDetailC la s s
F ield s
Pro p erties
Pro d uctRo w To tal
U nitPrice
I nvo iceClientI nvo iceRo w s
![Page 35: DDD](https://reader037.vdocuments.mx/reader037/viewer/2022110306/554f3676b4c90572088b4c50/html5/thumbnails/35.jpg)
Resolve the problem of paradigm mismatch!!!
Data Mapper
A layer of Mappers (473) that moves data between objects and a database while keeping them independent of each other and the mapper itself.
![Page 36: DDD](https://reader037.vdocuments.mx/reader037/viewer/2022110306/554f3676b4c90572088b4c50/html5/thumbnails/36.jpg)
Linq To SQLEntity FrameworkNHibernate
![Page 37: DDD](https://reader037.vdocuments.mx/reader037/viewer/2022110306/554f3676b4c90572088b4c50/html5/thumbnails/37.jpg)
![Page 38: DDD](https://reader037.vdocuments.mx/reader037/viewer/2022110306/554f3676b4c90572088b4c50/html5/thumbnails/38.jpg)
Very simple please… :D