Domain driven design ch1

Domain-Driven Design
chois79

12년 10월 8일 월요일

DDD(Domain-Driven Design)

• 가장 중요한 복잡성은 기술적인 것이 아닌 업무 도메인이다.

• DDD의 목표: 복잡한 도메인을 다뤄야 하는 소프트웨어 프로젝트에 박차를 가하는 것

• 이 책의 전제

• 대부분의 소프트웨어 프로젝트에서는 가장 먼저 도메인과 도메인 로직에 집중해야 한다

• 복잡한 도메인 설계는 모델을 기반으로 해야한다

• DDD를 위한 선행 조건

• 개발은 반복적인 주기를 토대로 진행되어야 한다

• 개발자와 도메인 전문가는 밀접한 관계에 있어야 한다


이 책의 구성

• 1부, 동작하는 도메인 만들기

• DDD의 배경 및 목표 제시

• 2부, 모델 주도 설계의 기본

• 모델과 실제 동작하는 소프트웨어 사이의 간극을 줄이는 법

• 3부, 더 심층적인 통찰력을 향한 리팩터링

• 반복적인 단계를 통한 모델의 정련

• 4부, 전략적 설계

• 복잡한 시스템, 더 큰 조직, 외부 시스템 및 기존 시스템과의 상호 작용


1부 동작하는 도메인 모델 만들기


개요(1/2)

• 모델이란?

• 대상을 단순화 한것

• 어떤 사실을 해석한 것

• 당면한 문제를 해결하는 것과 관련된 측면을 추상화

• 중요하지 않은 세부사항은 고려하지 않음


개요(2/2)

• 소프트웨어의 도메인

• 사용자가 프로그램을 사용하는 대상 영역

• 대게의 경우 컴퓨터와 관련이 없음

• 좋은 소프트웨어를 만들기 위해서는 도메인에 대한 폭 넓은 지식이 필요

• 도메인 지식은 복잡하고 양이 많음

• 모델 적용 필요

• 도메인 모델: 해당 지식을 엄격하게 구성하고, 선택적으로 추상화 한것


소프트웨어의 본질

• 사용자를 위해 도메인에 관련된 문제를 해결하는 것

• 도메인 연구는 소프트웨어 프로젝트에서 최우선 과제로 여겨지지 않는다

• 개발자는 자신의 실력을 훈련할수 있는 정량적인 문제를 추구함

• 도메인 업무는 무질서하고 개발자로서의 능력에 보탬이 될것 같지 않은 복잡하고 새로운 지식을 많이 요구

• 재능이 있는 기술자는 정교한 프레임워크 개발을 통해 기술을 바탕으로 문제를 해결하려 함

• 도메인을 학습하고 모델링하는 일은 다른이들의 몫으로 남겨둔다

• But, 소프트웨어 중심에 있는 복잡성은 정면으로 돌파해야 함

• 그렇지 않을 경우, 도메인과 무관한 소프트웨어를 만들 수 있다.


1부 에서는

• 모델은 지식의 정수만을 뽑아낸 것이다. - 1장

• 모델은 모든 팀 구성원이 사용하는 언어의 중추다 - 2장

• 모델과 핵심 설계는 서로 영향을 주며 구체화 된다 - 3장


Ch.1 지식 탐구


going to lead to the leap forward in productivity that they were looking for.
We tried having the PCB designers tell me exactly what the software should do. Bad idea. They
were great circuit designers, but their software ideas was a glimmer of hope in the reports they
The first few meetings were discouraging, but there usually involved reading in an ASCII file,
sorting it, writing it backalways involved "nets" and various and producing a A net, in this domain, clearly not
asked for. They out with some annotation, details about them. report. This was is
essentially a wire conductor that can connect any number of components on a PCB and carry an
going to lead to thesignal to everything it is connected to. We had the first element offor. domain model.
leap forward in productivity that they were looking the
PCB 분석were discouraging, but there was a glimmer of hope in the reports they
electrical

The first few meetings
예제(1/5)
asked for. They always involved "nets" and various details about them. A net, in this domain, is
Figure 1.1.
essentially a wire conductor that can connect any number of components on a PCB and carry an
•
electrical signal 모델의 첫번째it요소
도메인 to everything is connected to. We had the first element of the domain model.

• 네트를 통해 컴포넌트를 연결하고, 전기 신호를 전달
Figure 1.1.

I started drawing diagrams for them as we discussed the things they wanted the software to do. I
used an informal variant of object interaction diagrams to walk through scenarios.

Figure 1.2.

I started drawing diagrams for them as we discussed the things they wanted the software to do. I
used an informal variant of object interaction diagrams to walk through scenarios.

Figure 1.2.


Expert 1: It isn't enough to say a signal arrives at a ref-des, we have to know the pin.

Developer: Ref-des?

Expert 2: Same thing as a component instance. Ref-des is what it's called in a particular tool we
PCB 분석 예제(2/5)
use.

Expert 1: Anyhow, a net connects a particular pin of one instance to a particular pin of another.

Developer: Are you saying that a pin belongs to only one component instance and connects to
• 반복 커뮤니케이션 을 통한 정제
only one net?

Expert 1: Yes, that's right.

Expert 2: Also, every net has a topology, an arrangement that determines the way the elements
• 컨포넌트 인스턴스로 이름을 변경
of the net connect.

Developer: OK, how about this?

• Pin과 Topology 추가
Figure 1.3.

To focus our exploration, we limited ourselves, for a while, to studying one particular feature. A


"probe simulation" would trace the propagation of a signal to detect likely sites of certain kinds of
problems in the design.

Developer: I understand how the signal gets carried by the Net to all the Pins attached, but how
does it go any further than that? Does the Topology have something to do with it?

Expert 2: No. The component pushes the signal through.

Developer: We certainly can't model the internal behavior of a chip. That's way too complicated.

Expert 2: We don't have to. We can use a simplification. Just a list of pushes through the
component from certain Pins to certain others.

Developer: Something like this?
• 한가지 시나리오를 고려한 집중
[With considerable trial-and-error, together we sketched out a scenario.]

• “탐침 시뮬레이션”
Figure 1.4.

• 홈 로직 적용
Developer: But what exactly do you need to know from this computation?

Expert 2: We'd be looking for long signal delays—say, any signal path that was more than two or
three hops. It's a rule of thumb. If the path is too long, the signal may not arrive during the clock
cycle.

Developer: More than three hops.... So we need to calculate the path lengths. And what counts
as a hop?

Expert 2: Each time the signal goes over a Net, that's one hop.

Developer: So we could pass the number of hops along, and a Net could increment it, like this.

Figure 1.5.


Developer: The only part that isn't clear to me is where the "pushes" come from. Do we store
that data for every Component Instance?

Expert 2: The pushes would be the same for all the instances of a component.
• 도메인 로직 분석 of component determines the pushes. They'll be the same for every
Developer: So the type
instance?

• 신호 전달
Figure 1.6.

Expert 2: I'm not sure exactly what some of this means, but I would imagine storing push-
throughs for each component would look something like that.

Developer: Sorry, I got a little too detailed there. I was just thinking it through. . . . So, now,
where does the Topology come into it?

their understanding of how the model would play into the solution. A class diagram representing
that early model looks something like this.

• 모델을 바탕으로한 클래스 다이어 그램Figure 1.7.

• 무엇을 한 것인가? more part-time days of this, I automated test framework. Iattempt some code. I
After a couple
wrote a very simple prototype, driven by an
felt I understood enough to
avoided all
infrastructure. There was no persistence, and no user interface (UI). This allowed me to
concentrate on the behavior. I was able to demonstrate a simple probe simulation in just a few
more days. Although it used dummy data and wrote raw text to the console, it was nonetheless
• PCB 엔지니어 -> 개발자: 도메인 설명
doing the actual computation of path lengths using Java objects. Those Java objects reflected a
model shared by the domain experts and myself.

The concreteness of this prototype made clearer to the domain experts what the model meant and
how it related to the functioning software. From that point, our model discussions became more
• 개발자 -> PCB 엔지니어: 객체의 상호 작용 방식에 관한 시나리오 설명
interactive, as they could see how I incorporated my newly acquired knowledge into the model and
then into the software. And they had concrete feedback from the prototype to evaluate their own
thoughts.

Embedded in that model, which naturally became much more complicated than the one shown
• PCB 엔지니어와 개발자가 함께 브레인 스토밍을 통해 모델을 정제
here, was knowledge about the domain of PCB relevant to the problems we were solving. It
consolidated many synonyms and slight variations in descriptions. It excluded hundreds of facts
that the engineers understood but that were not directly relevant, such as the actual digital
features of the components. A software specialist like me could look at the diagrams and in
minutes start to get a grip on what the software was about. He or she would have a framework to
organize new information and learn faster, to make better guesses about what was important and
what was not, and to communicate better with the PCB engineers.

효과적인 모델링의 요소

• 모델과 구현의 연계

• 모델을 기반으로 하는 언어 정제

• 풍부한 지식이 담긴 모델 개발

• 모델의 정제

• 브레인 스토밍과 실험


지식 탐구

• 복잡한 도메인으로 부터 추상화하여 특정 지식을 엄밀히 표현하는 모델을 만들어 나가는 활동

• 폭포수 개발 방식

• 지식이 한 방향으로 흘러갈뿐 축척되지 않는다.

• 반복 프로세스를 활용한 방식

• 소프트웨어를 확장 가능한 상태로 유지 가능

• But, 프로그래머가 도메인에 관심이 없다면, 소프트웨어가 높은 수준에 이르기는 힘듬

• 지식 탐구는 혼자서 하는 활동이 아닌 개발자와 도메인 전문가가 함께 협업해야함

• 모델은 완벽해 질수 없으며, 다만 계속해서 발전해나갈 뿐이다.


지속적인 학습

• 소프트웨어를 개발하기 시작할때 우리는 충분히 알지 못한 상태에서 시작한다

• 모든 프로젝트에서는 지식이 새기 마련이다.

• 조직개편, 외주 제작

• 생산성이 뛰어난 팀은 지속적인 학습을 바탕으로 의식적으로 지식을 함양

• 핵심적인 부분을 개발하는데 초첨을 맞춘 고정 핵심 인력 양성을 통한 지식 축적

• 지식 탐구 프로세스 확립 필요

• 똑같이 지식을 얻고 의사소통 체계를 공유하며, 구현을 거쳐 피드백 고리를 완성하는 일을 모두
효과적으로 수행해야 함


Example
[ Team LiB ]

Extracting a Hidden Concept
Knowledge-Rich Design
Let's start 담긴 설계 (1/4)
풍부한 지식이 withvoyage of a ship. model that could be the basis of an application for
a very simple domain
The kind of knowledge captured in a model such as the PCB example goes beyond "find the
nouns." Business activities and rules are as central to a domain as are the entities involved; any
cargos onto a
domain will have various categories of concepts. Knowledge crunching yields models that reflect
this kind of insight. In parallel with model changes, developers refactor the implementation to
express the model, giving the application use of that knowledge.

It is with this move beyond entities and values that knowledge crunching can get intense, because
there may be actual inconsistency among business rules. Domain experts are usually not aware of

• 예제: 선박 화물 운송 예약 시스템
how complex their mental processes are as, in the course of their work, they navigate all these
rules, reconcile contradictions, and fill in gaps with common sense. Software can't do this. It is
through knowledge crunching in close collaboration with software experts that the rules are
clarified, fleshed out, reconciled, or placed out of scope. Figure 1.8.

Example
• 간단한 도메인 Hidden Concept
Extracting a 모델
Let's start with a very simple domain model that could be the basis of an application for booking
cargos onto a voyage of a ship.

• Cargo(화물), Voyage(운항) Figure 1.8.

We can state that the booking application's responsibility is to associate each Cargo wi
We can state that the booking application'sand tracking that Cargo with a
Voyage, recording responsibility is to associate each relationship. So far so good. Somewhere in the ap
Voyage, recording and tracking that relationship. So far so good. Somewhere in the application
• 구현 코드 could be a method like this: a method like this:
code there could be
code there

public int makeBooking(Cargo cargo, Voyage voyage) {
int confirmation = orderConfirmationSequence.next();
voyage.addCargo(cargo, confirmation);
return confirmation;
} int confirmation = orderConfirmationSequence.next();
Because there are always last-minute cancellations, standard practice in the shipping industry is to
accept more cargo than a particular vessel can carry on a voyage. This is called "overbooking."
Sometimesreturn confirmation; booking 110 percent of capacity. In
a simple percentage of capacity is used, such as
other cases complex rules are applied, favoring major customers or certain kinds of cargo.
}

Because there are always last-minute cancellations, standard practice in the shipping in
accept more cargo than a particular vessel can carry on a voyage. This is called "overbo

This is a basic strategy in the shipping domain that would be known to any businessperson in the
shipping industry, but it might not be understood by all technical people on a software team.

풍부한 지식이 담긴 설계 (2/4)
The requirements document contains this line:

This is a basic strategy in the10% overbooking.
Allow shipping domain that would be known to any businessperson in the
shipping industry, but it might not be understood by all technical people on a software team.
The class diagram and code
The requirements document contains this line: now look like this:
Allow 10% overbooking.

• 비즈니스 요구사항code now look like this:
The class diagram and 반영

Figure 1.9.

• 10% 초과 예약 허용 Figure 1.9.

• public int makeBooking(Cargo
구현 코드 cargo, Voyage voyage) {
double maxBooking = voyage.capacity() * 1.1;
if ((voyage.bookedCargoSize() + cargo.size()) > maxBooking)Voyage voyage)
public int makeBooking(Cargo cargo, {
return –1;
double maxBooking = voyage.capacity() * 1.1;
if ((voyage.bookedCargoSize() + cargo.size()) >
voyage.addCargo(cargo, confirmation); maxBooking)
return –1;
}
Now an important business rule is hidden as a guard clause in an application method. Later, in
Chapter 4, we'll look at the principle of LAYERED ARCHITECTURE, which would guide us to move the
over-booking}rule into a domain object, but for now let's concentrate on how we could make this
knowledge more explicit and accessible to everyone on the project. This will bring us to a similar
solution.
• 문제점 Now an important business rule is hidden as a guard clause in an application method. Later, in
1. As written, it is unlikely that any business expert could read this code to verify the rule, even
Chapter 4, we'll look at the principle of LAYERED ARCHITECTURE, which would guide us to move the
with the guidance of a developer.
over-booking rule into a domain object, but for now let's concentrate on how we could make this
2.
•the 개발자의 도움이 있더라도and accessible to everyone 읽고 규칙을 검증하지 못함 us to a similar
knowledge more explicit 업무전문가가 이 코드를 on the project. This will bring
It would be difficult for a technical, non-businessperson to connect the requirement text with
code.
solution.
If the rule were more complex, that much more would be at stake.

We can change the design to better capture this knowledge. The overbooking rule is a policy.
• 기술적인 측면만 담당하는 사람은 코드와 요구사항을 결부시키기가 어려울 것
Policy is another name for the designit is unlikely that any business expert is
1. As written, pattern known as STRATEGY (Gamma et al. 1995). It could read this code to verify the rule, even
usually motivated bywith the guidance of a developer. not needed here, as far as we
the need to substitute different rules, which is
know. But the concept we are trying to capture does fit the meaning of a policy, which is an
equally important motivation in domain-driven design. (See Chapter 12, "Relating Design Patterns
to the Model.") 2. It would be difficult for a technical, non-businessperson to connect the requirement text with
the code.

12년 10월 8일 월요일 If the rule were moreFigure 1.10. that much more would be at stake.
complex,


• Strategy Pattern 적용

The code is now:

The code is now:
• 코드 if (!overbookingPolicy.isAllowed(cargo, voyage)) return –1;
The code is now:

public int makeBooking(Cargo confirmation);
voyage.addCargo(cargo, cargo, Voyage voyage) {
if (!overbookingPolicy.isAllowed(cargo, voyage)) return –1;
if (!overbookingPolicy.isAllowed(cargo, voyage)) return –1;
}}
The new Overbooking Policy class contains this method:

}
public boolean isAllowed(Cargo cargo, Voyage voyage) {
return (cargo.size() + voyage.bookedCargoSize()) <=

• 초과 예약 정책}
(voyage.capacity() * 1.1);

public boolean isAllowed(Cargo cargo, that rule is
It will be clear to all that overbooking is a distinct policy, and the implementation of
Voyage voyage) {
explicit and separate. (cargo.size() + voyage.bookedCargoSize()) <=
return
public boolean that such an elaborate design be cargo, Voyage voyage) {
isAllowed(Cargo applied to
(voyage.capacity() focus on the every detail of minimize
Now, I am not recommending
domain. Chapter 15, (cargo.size() + voyage.bookedCargoSize()) <=
* 1.1); the
return "Distillation," goes into depth on how to important and
}or separate everythingcan be This example is and share show that a domain model anddesign has
corresponding design
else. meant to
(voyage.capacity()knowledge. The more explicit
used to secure * 1.1);
these advantages:
}
It 1. In order toclear design tonature of overbooking as a distincteveryonedistinct will
will be bring the to the this stage,overbooking and important businesspolicy, and the implementation of that rule is
have come to understand
all that the programmers and is a else involved
12년 10월 8일 월요일 explicit and separate. overbooking is a distinct policy, and the implementation of that rule is
It will not just an obscure all that
rule, be clear to calculation.


• 적용 결과

• 초과 예약 정책이 별개의 정책이라는 사실을 모두가 알수 있음

• 정책 구현이 명시적으로 드러나고 다른 구현가 분리 됨

• 저자의 의견

• 도메인의 모든 세부 사항에 이러한 정교한 설계를 적용하라는 것은 아니다

• 명시적인 설계의 이점

• 프로그래머와 그 밖의 모든 이가 중요한 업무 규칙임을 알게 되었음

• 프로그래머는 업무 전문가에게 그들이 이해할 수 있는 수준으로 기술적 산출물, 심지어 코드까지 보여 줄수 있
으며 이를 통해 피드백 고리가 완성됨


심층 모델

• 유용한 모델은 겉으로 드러나 있는 경우가 거의 없다.

• 도메인과 애플리케이션 요구사항을 이해하게 되면 처음에 생각했던 모델 요소를 버리
거나 관점을 바꾸게 됨

• 이를 통해 문제의 핵심을 관통하는 포착하기 힘든 추상화가 서서히 나타남

• 지식 탐구는 탐험과도 같아서 어디서 끝나게 될지 알지 못한다.


요약

• 소프트웨어의 복잡도는 도메인의 복잡도에서 비롯된다

• 수준 높은 소프트웨어 개발을 위해서는

• 도메인 전문가, 설계자, 개발자 모두가 도메인 지식을 갖추고 지속적으로 커뮤니케이션을 해야 한다.

• 이의 결과물인 도메인 모델은 분석, 설계, 개발 관점의 모든 사항을 반영할 수 있도록 지속적으로 발
전되어야 한다.

• 개발자 관점

• 도메인에 대한 지식을 갖추도록 해야 함

• 도메인과 관련된 지식을 코드에 최대한 반영해야 함


Domain driven design ch1

More Related Content

What's hot

Viewers also liked

Similar to Domain driven design ch1

More from HyeonSeok Choi

Recently uploaded

Domain driven design ch1