Domain driven design from theory to practice
Download
1 / 37

Domain-driven design from theory to practice - PowerPoint PPT Presentation


  • 166 Views
  • Uploaded on

Domain-driven design from theory to practice. Artur Trosin. Presentation for: Software as Craft 2009, 14-16 May. Before start. Why DDD nowadays?. Automation of various business domains High competition for a market place Growing business complexity Complexity becomes inevitable .

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Domain-driven design from theory to practice' - nile


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Domain driven design from theory to practice

Domain-driven designfrom theory to practice

Artur Trosin

Presentation for: Software as Craft 2009, 14-16 May



Why ddd nowadays
Why DDD nowadays?

  • Automation of various business domains

  • High competition for a market place

  • Growing business complexity

  • Complexity becomes inevitable


Why ddd
Why DDD?

  • Accidental complexity is bad

  • DDD is OO done right

  • Semantics over technology

  • Is discovered and NOT invented


Ddd benefits
DDD benefits?

  • Reduced complexity

  • High maintainability

  • Continuous collaboration and feedback

  • Brings to front the “Core Domain Knowledge”

  • Translations are reduced to minimum



Complexity of most software projects is understanding the business domain and not a technical one
Complexity of most software projects is understanding the business domain and not a technical one.





They are two different worlds
They are two different worlds!

Business Domain

(business experts)

Software Development

(development team)

We need to bring them together

(business domain & technical)

Successes depends on “how well you bring them together”


We need common view and language
We need common view and language!

Software Development

BusinessDomain

DomainModel

&

Ubiquities Language


Domain model is a rigorously organized and selective abstraction of the business domain knowledge
Domain Model- is a rigorously organized and selective abstraction of the (Business) Domain knowledge.


Ubiquitous Language - A language structured around the domain model and used by all team members to connect all the activities of the team with the software.


Ubiquitous language
Ubiquitous Language domain model and used by all team members to connect all the activities of the team with the software.

Business terms

developers don’t

understand

Technical terms

Domain Model Terms

Technical aspects

of design

DDD Patterns

Technical design

patterns

Business terms

everyone uses that

don’t appear in design

Bounded Contexts

S.O.L.I.D design

principles

Candidates to fold into model


Collaboration
Collaboration domain model and used by all team members to connect all the activities of the team with the software.

Domain Experts and Developers produce Model

Software Development

BusinessDomain

Produce

DomainModel

&

Ubiquities Language

Software

Reflected in

Based on

Direct mapping between business domain concepts and software artifacts


Building blocks
Building blocks domain model and used by all team members to connect all the activities of the team with the software.


Classic layering
Classic Layering domain model and used by all team members to connect all the activities of the team with the software.

UI

Record Sets or

Data Sets or

POCO or

POJO

Business Entities

Data Access

DB


Ddd recommended layering
DDD recommended-Layering domain model and used by all team members to connect all the activities of the team with the software.

Service Layer

UI

UI

Application

Domain Model

Domain

Infrastructure

Infrastructure

Service Getaways


Organizing domain logic patterns
Organizing Domain Logic Patterns domain model and used by all team members to connect all the activities of the team with the software.

Transaction Script

Table Module

Effort

to enhance

Domain Model

Complexity of Domain Logic

Source : PoEAA by Martin Fowler


A model expressed in software with: domain model and used by all team members to connect all the activities of the team with the software.

Life Cycle of domain object controlled by:

Repository

Services

Modules

Access with

Access with

Entities

Maintain integrity with

Express model with

Express model with

Express model with

Act as root of

Aggregates

Model-Driven Design

Express model with

Value Objects

Encapsulate with

X

Isolate domain with

Encapsulate with

Encapsulate with

Mutually exclusive

choice

Layered

Architecture

Encapsulate with

Factories

Smart UI


Associations
Associations domain model and used by all team members to connect all the activities of the team with the software.

Country

Country

Country

Period

President

President

President

*

*

*

Person

Person

Person


Entities
Entities domain model and used by all team members to connect all the activities of the team with the software.

  • An object defined primarily by its identity and not its attributes

  • Could be a person, a customer, an order, etc.

  • Not all objects have meaningful identities…

  • In some systems, a class may be an ENTITY, in others maybe not


Value objects
Value Objects domain model and used by all team members to connect all the activities of the team with the software.

  • Represent an aspect of the domain with NO conceptual identity

  • Use when you care about what something is, not who they are

  • Simple, immutable objects

  • NOT is same thing as a DTO [Fowler PoEAA]


Services
Services domain model and used by all team members to connect all the activities of the team with the software.

  • An operation offered as an interface that stands alone in the model

  • Does not fit into any of the objects in the model

  • Stateless

  • To be used judiciously (do not turn your app into a Transaction Script)

  • Use when an operation is an important domain concept


Modules
Modules domain model and used by all team members to connect all the activities of the team with the software.

  • Is larger grain of modeling and design

  • A method of organized related concepts

  • Low coupling and high cohesion

  • Communications mechanism.

  • Could be Administration, Invoicing, Reports,…


Aggregates
Aggregates domain model and used by all team members to connect all the activities of the team with the software.

  • A cluster of associated objects that is treated as a conceptual whole

  • Define consistency boundaries

  • A unit for the purpose of data changes

  • Is controlled by root


Factories
Factories domain model and used by all team members to connect all the activities of the team with the software.

  • Shifts complicated object creation to FACTORY

  • Enforce invariants

  • Decouple clients and hide creation details


Repositories
Repositories domain model and used by all team members to connect all the activities of the team with the software.

  • Provide illusion of an in-memory collection

  • Provide a simple model for obtaining persistent objects

  • Decouple domain model from persistence technology

  • Communicate design decisions about object access

  • IS NOT just DAO with CRUD


Cargo sample
Cargo Sample domain model and used by all team members to connect all the activities of the team with the software.


Collecting basic requirements
Collecting Basic requirements domain model and used by all team members to connect all the activities of the team with the software.

  • Book cargo in advance

  • Track key handling of customer cargo


  • Itinerary domain model and used by all team members to connect all the activities of the team with the software.


ad