Domain driven design from theory to practice
This presentation is the property of its rightful owner.
Sponsored Links
1 / 37

Domain-driven design from theory to practice PowerPoint PPT Presentation


  • 130 Views
  • Uploaded on
  • Presentation posted in: General

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 .

Download Presentation

Domain-driven design from theory to practice

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


Before start

Before start


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


Domain particular field of knowledge

Domain - particular field of knowledge


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.


Atom model

Domain Driven Design is based on models.

Atom Model


Even music has a model

Even Music has a Model


The key to controlling complexity is a good domain model

The key to controlling complexity is a good domain model.

Martin Fowler


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.


Domain driven design from theory to practice

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

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 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


Classic layering

Classic Layering

UI

Record Sets or

Data Sets or

POCO or

POJO

Business Entities

Data Access

DB


Ddd recommended layering

DDD recommended-Layering

Service Layer

UI

UI

Application

Domain Model

Domain

Infrastructure

Infrastructure

Service Getaways


Organizing domain logic patterns

Organizing Domain Logic Patterns

Transaction Script

Table Module

Effort

to enhance

Domain Model

Complexity of Domain Logic

Source : PoEAA by Martin Fowler


Domain driven design from theory to practice

A model expressed in software with:

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

Country

Country

Country

Period

President

President

President

*

*

*

Person

Person

Person


Entities

Entities

  • 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

  • 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

  • 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

  • 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

  • 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

  • Shifts complicated object creation to FACTORY

  • Enforce invariants

  • Decouple clients and hide creation details


Repositories

Repositories

  • 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


Collecting basic requirements

Collecting Basic requirements

  • Book cargo in advance

  • Track key handling of customer cargo


Domain driven design from theory to practice

  • Itinerary


  • Login