DDD Domain Driven Design - The way back to OO! Felipe Rodrigues de - - PowerPoint PPT Presentation

ddd
SMART_READER_LITE
LIVE PREVIEW

DDD Domain Driven Design - The way back to OO! Felipe Rodrigues de - - PowerPoint PPT Presentation

DDD Domain Driven Design - The way back to OO! Felipe Rodrigues de Almeida DDD blog.fratech.net 1 TOPICS THE PROBLEM Where are we missing the way? 3 THE CONCEPT What is DDD about? 4 Why use


slide-1
SLIDE 1 1

DDD

blog.fratech.net

DDD

Domain Driven Design - The way back to OO!

Felipe Rodrigues de Almeida

slide-2
SLIDE 2 2

DDD

blog.fratech.net

THE PROBLEM

Where are we missing the way? 3

THE CONCEPT

What is DDD about? 4 Why use DDD? 6 Where are we missing the way? (Fixes) 8 Layered Architecture 14

THE WAY BACK

Domain Objects 19 Entities, Services, Value Objects and Modules 21 Objects Life-Cycle 26

THE MEANING

Meaning What? 30 Ubiquitous Language 31 Supple Design 32 Strategic Design 34

TOPICS

slide-3
SLIDE 3 3

DDD

blog.fratech.net

THE PROBLEM

Where are we missing the way?

What is important? What is urgent?

  • Domain Models vs Manager Models (MOP)
  • Bad Communication
  • Architects thinking only about infra-structure
  • We have lost real Object Orientation
slide-4
SLIDE 4 4

DDD

blog.fratech.net

THE CONCEPT

What is DDD about?

Domain means “a sphere of knowledge, infmuency and activity “

  • f a situation

So, Domain Driven Design means, design (a software) driven (oriented) by it knowledge, infmuency and activity

slide-5
SLIDE 5 5

DDD

blog.fratech.net

THE CONCEPT

What is DDD about?

Above all, DDD is about to take the domain (a sphere of knowledge, infmuency and activity) and represent it in objects

DDD is the way back to OO!!!

slide-6
SLIDE 6 6

DDD

blog.fratech.net

THE CONCEPT

Why to use DDD?

More than just a concept, DDD is a process to fjnd out how to build a system and also to defjne how to treat specifjc business issues

slide-7
SLIDE 7 7

DDD

blog.fratech.net

THE CONCEPT

Why to use DDD?

Using DDD as a process you will be able to:

really use all those things your teacher said you could when you

  • were learning OO

avoid the Manager(Service) Model (MOP), which requires knowledge

  • about a specifjc implementation This kind o design is composed
  • nly by services

improve the comunication between your team and the customer

slide-8
SLIDE 8 8

DDD

blog.fratech.net

THE CONCEPT

Where are we missing the way? (Fixes)

What is important? What is urgent?

  • The business is important and the customer too Let`s give some

attention to business and customer comunication!

Important aspects cannot be left behind.

slide-9
SLIDE 9 9

DDD

blog.fratech.net

THE CONCEPT

Where are we missing the way? (Fixes)

Domain Models vs Manager Models(services) MOP

  • Domain Models treat the business like objects, services and

compositions, concerned about the way things are connected in the real world

Developing software is not about creating makers.

slide-10
SLIDE 10 10

DDD

blog.fratech.net

THE CONCEPT

Where are we missing the way? (Fixes)

Bad Comunication

  • The words you use when you are trying to explain a situation to

your customer, who doesn’t know the system, are responsible for misunderstanding Talking with him using his business terms, will make for better communication

Use the customers words to communicate!

slide-11
SLIDE 11 11

DDD

blog.fratech.net

THE CONCEPT

Where are we missing the way? (Fixes)

Architects thinking only about infra-structure

  • Architects are “freak“ people that usually think about technical

stufg and forget what is important to the customer

We have to think about business too.

Using DDD design will focus on business situations The internal transfer of knowledge is easier since communication will be improved as well

slide-12
SLIDE 12 12

DDD

blog.fratech.net

THE CONCEPT

Where are we missing the way? (Fixes)

We have lost real Object Orientation

  • Object orientation is about the use of objects and their

interactions to design software

At design time, we have to fjnd objects from the real world, to use for the specifjc case. Each domain model is singular and is not applicable to another model.

slide-13
SLIDE 13 13

DDD

blog.fratech.net

THE MEANING

Wait a Minute!

You said: “Each domain model is singular and is not applicable to another model.” If I am in an enterprise, why should I have more than 1 model to describe a single “thing” , perhaps even more that 1 model per application As a proponent of DRY, this doesn’t make sense to me

slide-14
SLIDE 14 14

DDD

blog.fratech.net

THE CONCEPT

Layered Architecture

A layered architecture at heart, is a way to separate concerns

Domain model depends on some infrastructure, but not

  • n a specifjc impementation.
slide-15
SLIDE 15 15

DDD

blog.fratech.net

THE CONCEPT

Presentation Layer

Responsible for interacting with the user, getting information from the user and showing information to the user

The presentation layer usually depends on the application layer or Data Source Layer!

slide-16
SLIDE 16 16

DDD

blog.fratech.net

THE CONCEPT

Application Layer

Works as delivery, coordinating tasks which the system is responsible for doing This layer has no business rules and is only responsible for delegating work to domain objects Its objects do not have state to refmect business situation, but can have state of a task’ s progress

Consists of a set of decorators, delegating calls to domain layer.

slide-17
SLIDE 17 17

DDD

blog.fratech.net

THE CONCEPT

Data Source Layer

A set of generic technical capabilities, providing support for higher layers

Here goes the most technical things!

slide-18
SLIDE 18 18

DDD

blog.fratech.net

THE CONCEPT

Domain Layer

Represents the concepts of business information and business situation A set of generic technical capabilities, providing support for higher layers

This layer is the heart of business software!

slide-19
SLIDE 19 19

DDD

blog.fratech.net

Domain Objects

Domain Objects are instances of real entities which hold any knowledgenemt, infmuency or activity of a situation We can fjgure out which domain objects we need, by talking to domain experts

Focusing on key words will help to defjne domain objects.

THE WAY BACK

slide-20
SLIDE 20 20

DDD

blog.fratech.net

THE WAY BACK

Domain Objects

slide-21
SLIDE 21 21

DDD

blog.fratech.net

THE WAY BACK

Entities

Any object which has an identity Usually is mapped to real world

  • bjects

Unique set of data.

slide-22
SLIDE 22 22

DDD

blog.fratech.net

THE WAY BACK

Value Objects

Used to describe characteristic of things It is part of the domain as much as entities, but is always under some model element, since it has no identity

Set of data without identity.

slide-23
SLIDE 23 23

DDD

blog.fratech.net

THE WAY BACK

Services

Services are a standalone interface, which holds operations that don’t fjt in any object in the model

It is not a thing, but a set of operations.

slide-24
SLIDE 24 24

DDD

blog.fratech.net

THE MEANING

Wait a Minute!

You’ve said earlier that DDD is better than service/manager models, but here you’re saying that DDD uses services Make sure that you describe how this type of service is difgerent from the other

slide-25
SLIDE 25 25

DDD

blog.fratech.net

THE WAY BACK

Modules

Organize your domain objects by modules, then whenever you need anything you know where it is

Don’t drive your modules by infrastrucure.

slide-26
SLIDE 26 26

DDD

blog.fratech.net

THE WAY BACK

Objects Life Cycle

Once you have decided the main objects of your system, you then know about its life cyle How will it interact in the model? Who is able to use it? Aggregate, Factory and Repository patterns stand for objects life cycle

The point is avoid showing internal complexity to the client.

slide-27
SLIDE 27 27

DDD

blog.fratech.net

THE WAY BACK

Aggregates

A set of objects with a unique interface for external calls Indicated for cases where you need keep consistent a set of objects

Aggregates always have a root responsible for being the interface for others elements.

slide-28
SLIDE 28 28

DDD

blog.fratech.net

THE WAY BACK

Factories

Responsible for creation of domain objects or even an entire aggregate

Required only when creation becomes too complicated.

slide-29
SLIDE 29 29

DDD

blog.fratech.net

THE WAY BACK

Repositories

Works as a “repository“ for domain objects Provides a simple interface for complex persistence operations Can encapsulate several data sources for a object

Make a repository whenever you fjnd a type that needs global access.

slide-30
SLIDE 30 30

DDD

blog.fratech.net

THE MEANING

Meaning what?

All software has a meaning Modeling is about fjnd the meaning

  • f software

Find the meaning, express it and you will have a great model.

slide-31
SLIDE 31 31

DDD

blog.fratech.net

THE MEANING

Ubiquitous Language

Created by the team, maintained by the team and for the team Ubiquitous Language has to be concerned about the business in question

Works like a dictionary, composed by the terms taken from Domain Experts.

slide-32
SLIDE 32 32

DDD

blog.fratech.net

THE MEANING

Supple Design

Created by the team, mainteined by the team and for the team Have to concern about the business in question

A set of concepts to make a fmexible design.

slide-33
SLIDE 33 33

DDD

blog.fratech.net

THE MEANING

Supple Design - Some Patterns

Intention-Revealing Interfaces x Standalone Classes x Conceptual Contours x

slide-34
SLIDE 34 34

DDD

blog.fratech.net

THE MEANING

Strategic Design

A set of good pratices to achieve a good Domain Model These patterns can works as a check list to improve the design quality

If you want you can express these patterns as documents.

slide-35
SLIDE 35 35

DDD

blog.fratech.net

Strategic Design

THE MEANING

slide-36
SLIDE 36 36

DDD

blog.fratech.net

Strategic Design

THE MEANING

slide-37
SLIDE 37 37

DDD

blog.fratech.net

Strategic Design

THE MEANING

slide-38
SLIDE 38 38

DDD

blog.fratech.net

Strategic Design

THE MEANING

slide-39
SLIDE 39 39

DDD

blog.fratech.net

Strategic Design

THE MEANING

slide-40
SLIDE 40 40

DDD

blog.fratech.net

Strategic Design

THE MEANING

slide-41
SLIDE 41 41

DDD

blog.fratech.net

Strategic Design

THE MEANING

slide-42
SLIDE 42 42

DDD

blog.fratech.net

Strategic Design

THE MEANING

slide-43
SLIDE 43 43

DDD

blog.fratech.net

THE MEANING

Wait a Minute!

Have you considered making a connection between “Published Language” and DSLs? I forgot about this aspect, but using DDD is a fantastic way to have an architecture that can transform into a DSL via this route

slide-44
SLIDE 44 44

DDD

blog.fratech.net

Strategic Design

THE MEANING

slide-45
SLIDE 45 45

DDD

blog.fratech.net

* The “Wait a minute!” questions are real questions from Ian Roughley after review this document. Thank you Ian! ** No, that man is not Ian.

WAIT A MINUTE!

slide-46
SLIDE 46 46

DDD

blog.fratech.net

THE END

Obrigado!

Felipe Rodrigues de Almeida felipe@fratech net blog fratech net