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 지식 탐구


PCB 분석 예제(1/5)

• 도메인 모델의 첫번째 요소

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

[ Team LiB ]

Chapter One. Crunching KnowledgeA few years ago, I set out to design a specialized software tool for printed-circuit board (PCB)design. One catch: I didn't know anything about electronic hardware. I had access to some PCBdesigners, of course, but they typically got my head spinning in three minutes. How was I going tounderstand enough to write this software? I certainly wasn't going to become an electricalengineer before the delivery deadline!

We tried having the PCB designers tell me exactly what the software should do. Bad idea. Theywere great circuit designers, but their software ideas usually involved reading in an ASCII file,sorting it, writing it back out with some annotation, and producing a report. This was clearly notgoing to lead to the leap forward in productivity that they were looking for.

The first few meetings were discouraging, but there was a glimmer of hope in the reports theyasked for. They always involved "nets" and various details about them. A net, in this domain, isessentially a wire conductor that can connect any number of components on a PCB and carry anelectrical signal to everything it 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. Iused an informal variant of object interaction diagrams to walk through scenarios.

Figure 1.2.

[ Team LiB ]

Chapter One. Crunching KnowledgeA few years ago, I set out to design a specialized software tool for printed-circuit board (PCB)design. One catch: I didn't know anything about electronic hardware. I had access to some PCBdesigners, of course, but they typically got my head spinning in three minutes. How was I going tounderstand enough to write this software? I certainly wasn't going to become an electricalengineer before the delivery deadline!

We tried having the PCB designers tell me exactly what the software should do. Bad idea. Theywere great circuit designers, but their software ideas usually involved reading in an ASCII file,sorting it, writing it back out with some annotation, and producing a report. This was clearly notgoing to lead to the leap forward in productivity that they were looking for.

The first few meetings were discouraging, but there was a glimmer of hope in the reports theyasked for. They always involved "nets" and various details about them. A net, in this domain, isessentially a wire conductor that can connect any number of components on a PCB and carry anelectrical signal to everything it 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. Iused an informal variant of object interaction diagrams to walk through scenarios.

Figure 1.2.



• 반복 커뮤니케이션 을 통한 정제

• 컨포넌트 인스턴스로 이름을 변경

• Pin과 Topology 추가

PCB Expert 1: The components wouldn't have to be chips.

Developer (Me): So I should just call them "components"?

Expert 1: We call them "component instances." There could be many of the same component.

Expert 2: The "net" box looks just like a component instance.

Expert 1: He's not using our notation. Everything is a box for them, I guess.

Developer: Sorry to say, yes. I guess I'd better explain this notation a little more.

They constantly corrected me, and as they did I started to learn. We ironed out collisions andambiguities in their terminology and differences between their technical opinions, and theylearned. They began to explain things more precisely and consistently, and we started to develop amodel together.

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

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 toonly one net?

Expert 1: Yes, that's right.

Expert 2: Also, every net has a topology, an arrangement that determines the way the elementsof the net connect.

Developer: OK, how about this?

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 ofproblems in the design.

Developer: I understand how the signal gets carried by the Net to all the Pins attached, but howdoes 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 thecomponent 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 orthree hops. It's a rule of thumb. If the path is too long, the signal may not arrive during the clockcycle.

Developer: More than three hops.... So we need to calculate the path lengths. And what countsas 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 storethat data for every Component Instance?

Expert 2: The pushes would be the same for all the instances of a component.

Developer: So the type of component determines the pushes. They'll be the same for everyinstance?

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?

Expert 1: That's not used for the probe simulation.

Developer: Then I'm going to drop it out for now, OK? We can bring it back when we get to thosefeatures.

And so it went (with much more stumbling than is shown here). Brainstorming and refining;questioning and explaining. The model developed along with my understanding of the domain and



• 도메인 로직 분석

• 신호 전달

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

Expert 2: The pushes would be the same for all the instances of a component.

Developer: So the type of component determines the pushes. They'll be the same for everyinstance?

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?

Expert 1: That's not used for the probe simulation.

Developer: Then I'm going to drop it out for now, OK? We can bring it back when we get to thosefeatures.

And so it went (with much more stumbling than is shown here). Brainstorming and refining;questioning and explaining. The model developed along with my understanding of the domain and



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

• 무엇을 한 것인가?

• PCB 엔지니어 -> 개발자: 도메인 설명

• 개발자 -> PCB 엔지니어: 객체의 상호 작용 방식에 관한 시나리오 설명

• PCB 엔지니어와 개발자가 함께 브레인 스토밍을 통해 모델을 정제

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

Figure 1.7.

After a couple more part-time days of this, I felt I understood enough to attempt some code. Iwrote a very simple prototype, driven by an automated test framework. I avoided allinfrastructure. There was no persistence, and no user interface (UI). This allowed me toconcentrate on the behavior. I was able to demonstrate a simple probe simulation in just a fewmore days. Although it used dummy data and wrote raw text to the console, it was nonethelessdoing the actual computation of path lengths using Java objects. Those Java objects reflected amodel shared by the domain experts and myself.

The concreteness of this prototype made clearer to the domain experts what the model meant andhow it related to the functioning software. From that point, our model discussions became moreinteractive, as they could see how I incorporated my newly acquired knowledge into the model andthen into the software. And they had concrete feedback from the prototype to evaluate their ownthoughts.

Embedded in that model, which naturally became much more complicated than the one shownhere, was knowledge about the domain of PCB relevant to the problems we were solving. Itconsolidated many synonyms and slight variations in descriptions. It excluded hundreds of factsthat the engineers understood but that were not directly relevant, such as the actual digitalfeatures of the components. A software specialist like me could look at the diagrams and inminutes start to get a grip on what the software was about. He or she would have a framework toorganize new information and learn faster, to make better guesses about what was important andwhat was not, and to communicate better with the PCB engineers.

As the engineers described new features they needed, I made them walk me through scenarios ofhow the objects interacted. When the model objects couldn't carry us through an importantscenario, we brainstormed new ones or changed old ones, crunching their knowledge. We refinedthe model; the code coevolved. A few months later the PCB engineers had a rich tool thatexceeded their expectations.

[ Team LiB ]


효과적인 모델링의 요소

• 모델과 구현의 연계

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

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

• 모델의 정제

• 브레인 스토밍과 실험


지식 탐구

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

• 폭포수 개발 방식

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

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

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

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

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

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


지속적인 학습

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

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

• 조직개편, 외주 제작

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

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

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

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


풍부한 지식이 담긴 설계 (1/4)

• 예제: 선박 화물 운송 예약 시스템

• 간단한 도메인 모델

• Cargo(화물), Voyage(운항)

• 구현 코드

[ Team LiB ]

Knowledge-Rich DesignThe kind of knowledge captured in a model such as the PCB example goes beyond "find thenouns." Business activities and rules are as central to a domain as are the entities involved; anydomain will have various categories of concepts. Knowledge crunching yields models that reflectthis kind of insight. In parallel with model changes, developers refactor the implementation toexpress the model, giving the application use of that knowledge.

It is with this move beyond entities and values that knowledge crunching can get intense, becausethere may be actual inconsistency among business rules. Domain experts are usually not aware ofhow complex their mental processes are as, in the course of their work, they navigate all theserules, reconcile contradictions, and fill in gaps with common sense. Software can't do this. It isthrough knowledge crunching in close collaboration with software experts that the rules areclarified, fleshed out, reconciled, or placed out of scope.

ExampleExtracting a Hidden Concept

Let's start with a very simple domain model that could be the basis of an application for bookingcargos onto a voyage of a ship.

Figure 1.8.

We can state that the booking application's responsibility is to associate each Cargo with aVoyage, recording and tracking that relationship. So far so good. Somewhere in the applicationcode there could be a method like this:

public int makeBooking(Cargo cargo, Voyage voyage) { int confirmation = orderConfirmationSequence.next(); voyage.addCargo(cargo, confirmation); return confirmation;}

Because there are always last-minute cancellations, standard practice in the shipping industry is toaccept more cargo than a particular vessel can carry on a voyage. This is called "overbooking."Sometimes a simple percentage of capacity is used, such as booking 110 percent of capacity. Inother cases complex rules are applied, favoring major customers or certain kinds of cargo.

[ Team LiB ]

Knowledge-Rich DesignThe kind of knowledge captured in a model such as the PCB example goes beyond "find thenouns." Business activities and rules are as central to a domain as are the entities involved; anydomain will have various categories of concepts. Knowledge crunching yields models that reflectthis kind of insight. In parallel with model changes, developers refactor the implementation toexpress the model, giving the application use of that knowledge.

It is with this move beyond entities and values that knowledge crunching can get intense, becausethere may be actual inconsistency among business rules. Domain experts are usually not aware ofhow complex their mental processes are as, in the course of their work, they navigate all theserules, reconcile contradictions, and fill in gaps with common sense. Software can't do this. It isthrough knowledge crunching in close collaboration with software experts that the rules areclarified, fleshed out, reconciled, or placed out of scope.

ExampleExtracting a Hidden Concept

Let's start with a very simple domain model that could be the basis of an application for bookingcargos onto a voyage of a ship.

Figure 1.8.

We can state that the booking application's responsibility is to associate each Cargo with aVoyage, recording and tracking that relationship. So far so good. Somewhere in the applicationcode there could be a method like this:

public int makeBooking(Cargo cargo, Voyage voyage) { int confirmation = orderConfirmationSequence.next(); voyage.addCargo(cargo, confirmation); return confirmation;}

Because there are always last-minute cancellations, standard practice in the shipping industry is toaccept more cargo than a particular vessel can carry on a voyage. This is called "overbooking."Sometimes a simple percentage of capacity is used, such as booking 110 percent of capacity. Inother cases complex rules are applied, favoring major customers or certain kinds of cargo.



• 비즈니스 요구사항 반영

• 10% 초과 예약 허용

• 구현 코드

• 문제점

• 개발자의 도움이 있더라도 업무전문가가 이 코드를 읽고 규칙을 검증하지 못함

• 기술적인 측면만 담당하는 사람은 코드와 요구사항을 결부시키기가 어려울 것

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

The requirements document contains this line:

Allow 10% overbooking.

The class diagram and code now look like this:

Figure 1.9.

public int makeBooking(Cargo cargo, Voyage voyage) { double maxBooking = voyage.capacity() * 1.1; if ((voyage.bookedCargoSize() + cargo.size()) > maxBooking) return –1; int confirmation = orderConfirmationSequence.next(); voyage.addCargo(cargo, confirmation); return confirmation;}

Now an important business rule is hidden as a guard clause in an application method. Later, inChapter 4, we'll look at the principle of LAYERED ARCHITECTURE, which would guide us to move theover-booking rule into a domain object, but for now let's concentrate on how we could make thisknowledge more explicit and accessible to everyone on the project. This will bring us to a similarsolution.

As written, it is unlikely that any business expert could read this code to verify the rule, evenwith the guidance of a developer.

1.

It would be difficult for a technical, non-businessperson to connect the requirement text withthe code.

2.

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 design pattern known as STRATEGY (Gamma et al. 1995). It isusually motivated by the need to substitute different rules, which is not needed here, as far as weknow. But the concept we are trying to capture does fit the meaning of a policy, which is anequally important motivation in domain-driven design. (See Chapter 12, "Relating Design Patternsto the Model.")

Figure 1.10.

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

The requirements document contains this line:

Allow 10% overbooking.

The class diagram and code now look like this:

Figure 1.9.

public int makeBooking(Cargo cargo, Voyage voyage) { double maxBooking = voyage.capacity() * 1.1; if ((voyage.bookedCargoSize() + cargo.size()) > maxBooking) return –1; int confirmation = orderConfirmationSequence.next(); voyage.addCargo(cargo, confirmation); return confirmation;}

Now an important business rule is hidden as a guard clause in an application method. Later, inChapter 4, we'll look at the principle of LAYERED ARCHITECTURE, which would guide us to move theover-booking rule into a domain object, but for now let's concentrate on how we could make thisknowledge more explicit and accessible to everyone on the project. This will bring us to a similarsolution.

As written, it is unlikely that any business expert could read this code to verify the rule, evenwith the guidance of a developer.

1.

It would be difficult for a technical, non-businessperson to connect the requirement text withthe code.

2.

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 design pattern known as STRATEGY (Gamma et al. 1995). It isusually motivated by the need to substitute different rules, which is not needed here, as far as weknow. But the concept we are trying to capture does fit the meaning of a policy, which is anequally important motivation in domain-driven design. (See Chapter 12, "Relating Design Patternsto the Model.")

Figure 1.10.



• Strategy Pattern 적용

• 코드

• 초과 예약 정책

The code is now:

public int makeBooking(Cargo cargo, Voyage voyage) { if (!overbookingPolicy.isAllowed(cargo, voyage)) return –1; int confirmation = orderConfirmationSequence.next(); voyage.addCargo(cargo, confirmation); return confirmation;}

The new Overbooking Policy class contains this method:

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

It will be clear to all that overbooking is a distinct policy, and the implementation of that rule isexplicit and separate.

Now, I am not recommending that such an elaborate design be applied to every detail of thedomain. Chapter 15, "Distillation," goes into depth on how to focus on the important and minimizeor separate everything else. This example is meant to show that a domain model andcorresponding design can be used to secure and share knowledge. The more explicit design hasthese advantages:

In order to bring the design to this stage, the programmers and everyone else involved willhave come to understand the nature of overbooking as a distinct and important businessrule, not just an obscure calculation.

1.

Programmers can show business experts technical artifacts, even code, that should beintelligible to domain experts (with guidance), thereby closing the feedback loop.

2.

[ Team LiB ]

The code is now:







1.


2.

[ Team LiB ]

The code is now:







1.


2.

[ Team LiB ]



• 적용 결과

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

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

• 저자의 의견

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

• 명시적인 설계의 이점

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

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


심층 모델

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

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

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

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


요약

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

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

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

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

• 개발자 관점

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

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


domain driven design ch1

Technology