Domain driven design ch3

Ch.3 모델과 구현의 연계
(Domain Driven Design)
chois79

12년 10월 8일 월요일

이 장에서는?

• Non-DDD의 문제점

• 분석한 결과로 도출된 모델이 실제 코드에 반영되지 않음

• Why?

• 비즈니스 분석 측면에서 올바르게 모델이 도출 됨.

• But, 개발 관점에서의 이슈가 포함되어 있지 않음

• Then, 도메인 주도 설계에서 필요로 하는 모델링 접근법은?


MODEL-DRIVEN DESIGN(1/4)

• 코드와 기반이 되는 모델이 긴밀하게 연결될 경우

• 코드에의미가 부여되고, 모델과 코드가 서로 대응하게 됨

• 모델과 코드를 긴밀하게 연결 하는 것은 어려운 일이다.

• 모델과 코드는 엄연히 다른 것

• 분석 모델

• 업무 도메인의 개념만을 체계화하고 해당 업무 도메인을 분석한 결과물

• 설계를 염두에 둔 것이 아니기 때문에, 모델과 설계의 연결을 분석 모델로 진행하는 것은 비 현실적

• 중요한 발견은 설계/구현 단계에서 드러남



• 설계가 도메인 모델과 대응하지 않을 경우

• 모델의 가치가 없어진다.

• 모델과 설계 기능 사의의 관계 이해 불가

• 설계가 변경되었을 경우, 유지보수가 불가능

• 각 단계에서의 지식활동에서 얻은 통찰력이 서로에게 반영되지 못함

• 모델을 충분히 반영하지 못한 소프트웨어

• 올바른 기능에 대한 정확도 판단이 어려움

• 행위를 설명하지 못하고 그저 유익한 일을 수행하는 메커니즘 수준


• 분석

• 도메인의 근본적인 개념을 알기 쉽게 표현력 있는 방식으로 포착

• 설계

• 대상 배포 환경에서 효율적으로 수행되고 애플리케이션에서 다뤄야할 문제를 올바르게 해결해 줄수 있는 구성요소를 기술

• MDD(MODEL-DRIVEN DESIGN)

• 순수하게 기술적인 쟁점은 배제함으로써 설계상의 각 객체는 모델에서 기술한 개념적 역할을 수행하게 함

• 도메인 추상화, 애플리케이션의 문제 해결 관점에서 효과적인 단일 모델을 선택

• 기술적 고려사항 탓에 분석이 심각하게 타협된 상태에 놓여선 안됨

• 도메인 아이디어는 반영하지만 소프트웨어의 설계 원칙을 따르지 않은 설계는 배제되어야 함



• MDD 실천지침

• 설계시 도메인 모델을 있는 그대로 반영해서 설계와 모델의 대응을 명확히 함

• 모델로부터 설계와 기본적인 책임 할당에 사용한 용어를 도출

• 코드를 작성할때 도출한 용어를 사용하여 모델을 반영

• 코드의 변경이 모델의 변경으로 이어질 수 있음

• 모델을 재검토해서 더욱 자연스럽게 구현될 수 있도록 수정

• 구현을 모델과 올바르게 묶으려면 객체지향과 같은 모델링 패러다임을 지원하는 개발 도구와 언어가
필요


모델링 패러다임과 도구 지원

• MDD의 성과를 위해서는 인간의 오차범위 내에서 정확하게 모델과 구현이 직접적으로 대응이 되어야 함

• 모델링의 개념에 직접적으로 대응되는 것을 만들어 낼수 있는 소프트웨어 도구가 뒷받침 되는 모델링 패러다임 내에서 업무를 수행하는
것이 필수적

• 객제치향 프로그래밍 언어

• 모델링 패러다임에 근거하고 모델의 구성요소에 대한 구현을 제공하기때문에 매우 효과적이다

• 객체 설계에서의 진정한 도약은 코드가 모델의 개념을 표현할때 나온다

• 절차적인 언어

• 절차적인 언어에 대응되는 모델링 패러다임이 없기 때문에 MDD 적용이 어려움

• 도메인의 개념을 담지 못함

• 예외) 포트란으로 수학적 모델 풀기

• 수학적 모델은 함수가 주요한 개념적 구성요소


모델링 패러다임과 도구 지원 - 예제(1/3)
anticipated paths of execution, rather than by conceptual connections in the domain model.
• PCB 레이아웃 도구 Before I ever heard of object-oriented programming, I wrote fortran programs to solve
mathematical models, which is just the sort of domain in which fortran excels. Mathematical
functions are the main conceptual component of such a model and can be cleanly expressed in
fortran. Even so, there is no way to capture higher level meaning beyond the functions. Most non-
• 네트가 서로 교차하거나 방해하지 않게 모든 네트의 물리적인 배열 방법을 찾는 것
mathematical domains don't lend themselves to MODEL-DRIVEN DESIGN in procedural languages
because the domains are not conceptualized as math functions or as steps in a procedure.

Object-oriented design, the paradigm that currently dominates the majority of ambitious projects,
is the approach used primarily in this book.

• 제약조건
Example
From Procedural to MODEL-DRIVEN
• 네트 각각이 고유한 레이아웃in규칙을1,가지고 circuit board (PCB) can be viewed as a collection of electrical
As discussed Chapter a printed 있음
conductors (called nets) connecting the pins of various components. There are often tens of
thousands of nets. Special software, called a PCB layout tool, finds a physical arrangement for all
the nets so that they don't cross or interfere with each other. It does this by optimizing their paths
while satisfying an enormous number of constraints placed by the human designers that restrict
• 특정 그룹에 속하는 여러 네트는 서로 동일한 규칙을 공유해야 함
the way they can be laid out. Although PCB layout tools are very sophisticated, they still have
some shortcomings.

One problem is that each of these thousands of nets has its own set of layout rules. PCB engineers
see many nets as belonging to natural groupings that should share the same rules. For example,
• Ex) 생산성 향상을 위해 여러개의 네트를 하나의 버스로 묶어 관리
some nets form buses.

Figure 3.2. An explanatory diagram of buses and nets

By lumping nets into a bus, perhaps 8 or 16 or 256 at a time, the engineer cuts the job down to a
more manageable size, improving productivity and reducing errors. The trouble is, the layout tool
has no such concept as a bus. Rules have to be assigned to tens of thousands of nets, one net at a
time.

. . .

It stores the layout rules in a file format something like this:
It stores the layout rules in a file format something like this:

Net Name Rule Type Parameters

모델링 패러다임과 도구 지원 - 예제(2/3) Net Name

Xyz1
Xyz1
Rule Type
--------
--------
---------
---------
min_linewidth
Parameters
----------
----------
min_linewidth
5
5
Xyz1 max_delay 15
Xyz1 max_delay 15
Xyz2 min_linewidth 5
Xyz2 max_delay 15
Xyz2 max_delay 15
. . .
• 기계적인 설계 - 절차적인 방식 . . .

The engineers carefully use a naming convention for the nets so that an alphabetic
1) 네트 이름으로 네트 목록 파일을 정렬 The engineers carefully use a naming convention for the nets so that an alphabetical sort of t
data file will place the nets of a bus together in a sorted file. Then their script can
data file will place the nets of a bus together in a sorted file. Then their script can parse the f
and modify each net based on its bus. Actual code to parse, manipulate, and write
and modify each net based on its bus. Actual code to parse, manipulate, and write the files is
too verbose and opaque to serve this example, so I'll just list the steps in the proc
2) 버스 이름 패턴으로 시작하는 첫 번째 네트를 찾으면서 각 줄을 읽는다 serve this example, so I'll just list the steps in the procedure.
too verbose and opaque to

1. Sort 1. Sort net list file name.
net list file by net by net name.
3) 이름이 일치하는 각 줄에서 해당 줄을 파싱해서 네트의 이름을 each line in file, first one that one that starts with bus na
A Mechanistic Design 2. Read 2. Read 구한다 file, seeking seeking first starts with bus name patter
each line in
3. For each line with matching name, parse line to line to get net name.
3. For each line with matching name, parse get net name.
Bus에 대한 명시적인 개념이 포함되지 않음
Desperate engineers worked aroundAppend net name with rule text to rules to rules file.
4. this limitation in the layout tool by writingtext file.
4. Append net name with rule scripts that parse
4) 규칙 텍스트가 있는 네트data files and insert추가한다 Repeat fromfile, until left of an entire bus at a matches bus name.
the layout tool's 이름을 규칙 파일에 Repeat from into the 3 applying themno longer matches bus name.
5. rules5.directly 3 until left of line to line no longer
time.

5) 나머지 줄이 더는 버스 stores each circuit connectiontheainput반복한다 rulelooks something like this:
The layout tool 이름과 일치하지 않을 the input 과정부터 list file, which this: as this:
So 때까지 3) of net rule such as such
So in bus of a bus

목록
Net Name Component.Pin Bus규칙 Bus Name Type
Name Rule Rule Type Parameters
Parameters
-------- ------------- --------
-------- --------- ----------
--------- ----------
파일 파일 Xyz
Xyz0 A.0, B.0 Xyz max_viasmax_vias 3 3
Xyz1 A.1, B.1
Xyz2 A.2, B.2
. . . would result in addingin adding net rules to the file like these:
would result net rules to the file like these:

format something like this: Type Parameters
It stores the layout rules in a fileNet Name Net Name Type
Rule Rule Parameters
-------- --------
--------- --------- ----------
----------
결과 . . . . . .
Net Name Rule Type Parameters
Xyz0 Xyz0 max_viasmax_vias 3 3
-------- --------- ----------
Xyz1 max_delay 15
Xyz2 min_linewidth
. . . . . .
5
Xyz2 max_delay 15
. . .

different file format (and there are several) would require starting from scratch, even though the
concept of grouping buses and applying rules to them is the same. If you wanted richer
functionality or interactivity, you would have to pay for every inch.

What the script writers were trying to do was to supplement the tool's domain model with the
concept of "bus." Their implementation infers the bus's existence through sorts and string
matches, but it does not explicitly deal with the concept.

모델링 패러다임과 도구 지원 - 예제(3/3)
A Model-Driven Design

The preceding discussion has already described the concepts the domain experts use to think
about their problems. Now we need to organize those concepts explicitly into a model we can base
software on.

• 모델 주도 class diagram oriented toward efficient assignment of
Figure 3.3. A
설계 layout rules
abstract class AbstractNet {
private Set rules;
void assignRule(LayoutRule rule) {
rules.add(rule);
}
Set assignedRules() {
return rules;
}
}

class Net extends AbstractNet {
private Bus bus;
Set result = new HashSet();
Bus에 대한 개념을 사용
With these objects implemented in an object-oriented language, the core functionality becomes
result.addAll(super.assignedRules());
result.addAll(bus.assignedRules());
almost trivial.
return result;
The assignRule() method can be implemented on Abstract Net. The assignedRules() method }
on Net takes its own rules and its Bus's rules.
}
• 장점
abstract class AbstractNet {
private Set rules;
public void testBusRuleAssignment() {
void assignRule(LayoutRule rule) { Net a0 = new Net("a0");
rules.add(rule);
} Net a1 = new Net("a1");
Bus a = new Bus("a");
• Bus에 대한 개념이 명확히 드러남
a.addNet(a0);
a.addNet(a1);
NetRule minWidth4 = NetRule.create(MIN_WIDTH, 4);
a.assignRule(minWidth4);
assertTrue(a0.assignedRules().contains(minWidth4));
• 테스트가 용이 assertEquals(minWidth4, a0.getRule(MIN_WIDTH));
assertEquals(minWidth4, a1.getRule(MIN_WIDTH));
}


내부 드러내기: 왜 모델이 사용자에게 중요한가?

• 사용자가 바라보는 것과 시스템이 불일치한다면 혼란을 초래한다

• Ex) Internet Explorer의 즐겨찾기 기능

• 사용자 관점: 세션간 지속되는 웹사이트 이름 목록

• 구현 관점: URL이 저장된 파일

• 문제점: 파일 이름에 포함될 수 없는 문자는 저장될 수 없음, 사용자가 원하는 것은 아님

• 대상이 되는 두 모델이 다르기 때문에 문제 발생

• 설계가 사용자와 도메인 전문가의 관심사를 반영하는 모델에 기반을 두면 설계의 골격이 더 큰 범위에서 사용자에
게 드러날 수 있다

• 사용자가 소프트웨어의 잠재력을 좀 더 많이 접하게 되어 일관성 있고, 예상 가능한 행위를 한다


HANDS-ON MODELER(실천적 모델러) (1/2)
• 제조업은 소프트웨어 개발 분야에서 인기 있는 Metaphor

• 숙련된 엔지니어는 설계, 덜 숙련된 엔지니어는 제품을 조립

• 이는 ‘소프트웨어 개발은 모든것이 설계다’라는 단순한 이유로 많은 프로젝트를 엉망으로 만듬

• 분석, 모델링, 설계, 프로그래밍을 지나치게 구분하는 것은 MDD와 상충

• 각각의 책임이 명확히 분리되어 있고, 협업을 하지 못하는 경우

• 개발자가 모델에 대한 책임을 못느낄 경우

• 코드의 변경이 곧 모델의 변경임을 인식하지 못하면 리팩토링은 모델을 약하시킨다

• 모델러가 구현 프로세스와 분리 되어 있을 경우

• 구현상의 제약조건을 감안하는 능력이 없어짐

• 설계자가 구현을 못해 개발자와 업무 단절이 생기는 경우

• 숙련된 설계자의 지식과 솜씨는 결코 다른 개발자에게 전해지지 못함


HANDS-ON MODELER(실천적 모델러) (2/2)

• 실천적 모델러를 위한 가이드

• 모델에 기여하는 모든 기술자는 일차적 역할과 상관 없이 코드를 접하는데 시간을 투자
해야한다

• 코드를 변경하는 책임이 있는 이들은 코드를 통해 모델을 표현하는 법을 배워야 한다

• 모든 개발자는 모델에 관한 일정 수준의 토의에 깊이 관여해야 하고, 도메인 전문가와
도 접촉해야 한다

• 모델에 기여하는 사람은 코드를 접하는 사람들과 UBIQUITOUS LANGUAGE를 토
대로 모델의 아이디어를 나누는데 적극 동참해야 한다


Domain driven design ch3

Recommandé

Recommandé

Contenu connexe

Similaire à Domain driven design ch3

Similaire à Domain driven design ch3 (20)

Plus de HyeonSeok Choi

Plus de HyeonSeok Choi (20)

Domain driven design ch3