Antonio Radesca http://dotnetslackers.com/Community/blogs/antrad/ Domain Driven Design
Business Requirement <>Business Modeling<>Software Design
Business Modeling Software Design Order Customer Product 1..* Domain Model Process (text) Business Requirement
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 ”
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
Design practices and patterns
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
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
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
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
Diagrams are a means of communication and explanation
They serve these ends if they are minimal
They represent the skeletons of ideas
Diagram communicate and explane model
Documents and diagrams must complement code and speechs
The vital details are capturated into CODE!
Cargo cargoId origin destination Routing service Origin Destination Populate Cargo DB table:cargo_booking Cargo_Id,Transport,Load,Unload
Routing Service A Route Specification An Itinerary satisfyting the Route specification
MDD support DDD
Structure software around some set of concepts
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
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
Layering User Interface (Presentation Layer) Responsible for presenting information to the user and interpreting user commands. Application Layer This is a thin layer which coordinates the application activity. It does not contain business logic. It does not hold the state of the business objects, but it can hold the state of an application task progress. Domain Layer This layer contains information about the domain. This is the heart of the business software. The state of business objects is held here. Persistence of the business objects and possibly their state is delegated to the infrastructure layer. Infrastructure Layer This layer acts as a supporting library for all the other layers. It provides communication between layers, implements persistence for business objects, contains supporting libraries for the user interface layer, etc.
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.
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.
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
Creates and manage complex objects. Abstract Factory Provides an interface for creating families of related or dependent projects without specifying their concrete classes.
A good design helps to mantain project in consistent state and integrity model.
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)
Next time…. :D
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.
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
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)
A little bit…. :D
ORM SOA Patterns Refactoring TDD IOC
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.