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)

• PCB 레이아웃 도구

• 네트가 서로 교차하거나 방해하지 않게 모든 네트의 물리적인 배열 방법을 찾는 것

• 제약조건

• 네트 각각이 고유한 레이아웃 규칙을 가지고 있음

• 특정 그룹에 속하는 여러 네트는 서로 동일한 규칙을 공유해야 함

• Ex) 생산성 향상을 위해 여러개의 네트를 하나의 버스로 묶어 관리

anticipated paths of execution, rather than by conceptual connections in the domain model.

Before I ever heard of object-oriented programming, I wrote fortran programs to solvemathematical models, which is just the sort of domain in which fortran excels. Mathematicalfunctions are the main conceptual component of such a model and can be cleanly expressed infortran. 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 languagesbecause 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.

ExampleFrom Procedural to MODEL-DRIVEN

As discussed in Chapter 1, a printed circuit board (PCB) can be viewed as a collection of electricalconductors (called nets) connecting the pins of various components. There are often tens ofthousands of nets. Special software, called a PCB layout tool, finds a physical arrangement for allthe nets so that they don't cross or interfere with each other. It does this by optimizing their pathswhile satisfying an enormous number of constraints placed by the human designers that restrictthe way they can be laid out. Although PCB layout tools are very sophisticated, they still havesome shortcomings.

One problem is that each of these thousands of nets has its own set of layout rules. PCB engineerssee many nets as belonging to natural groupings that should share the same rules. For example,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 amore manageable size, improving productivity and reducing errors. The trouble is, the layout toolhas no such concept as a bus. Rules have to be assigned to tens of thousands of nets, one net at atime.12년 10월 8일 월요일


• 기계적인 설계 - 절차적인 방식

1) 네트 이름으로 네트 목록 파일을 정렬

2) 버스 이름 패턴으로 시작하는 첫 번째 네트를 찾으면서 각 줄을 읽는다

3) 이름이 일치하는 각 줄에서 해당 줄을 파싱해서 네트의 이름을 구한다

4) 규칙 텍스트가 있는 네트 이름을 규칙 파일에 추가한다

5) 나머지 줄이 더는 버스 이름과 일치하지 않을 때까지 3) 과정부터 반복한다

A Mechanistic Design

Desperate engineers worked around this limitation in the layout tool by writing scripts that parsethe layout tool's data files and insert rules directly into the file, applying them to an entire bus at atime.

The layout tool stores each circuit connection in a net list file, which looks something like this:

Net Name Component.Pin-------- -------------Xyz0 A.0, B.0Xyz1 A.1, B.1Xyz2 A.2, B.2. . .

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

Net Name Rule Type Parameters-------- --------- ----------Xyz1 min_linewidth 5Xyz1 max_delay 15Xyz2 min_linewidth 5Xyz2 max_delay 15. . .

The engineers carefully use a naming convention for the nets so that an alphabetical sort of thedata file will place the nets of a bus together in a sorted file. Then their script can parse the fileand modify each net based on its bus. Actual code to parse, manipulate, and write the files is justtoo verbose and opaque to serve this example, so I'll just list the steps in the procedure.

1. Sort net list file by net name.2. Read each line in file, seeking first one that starts with bus name pattern.3. For each line with matching name, parse line to get net name.4. Append net name with rule text to rules file.5. Repeat from 3 until left of line no longer matches bus name.

So the input of a bus rule such as this:

Bus Name Rule Type Parameters-------- --------- ----------Xyz max_vias 3

would result in adding net rules to the file like these:

Net Name Rule Type Parameters-------- --------- ----------. . .Xyz0 max_vias 3Xyz1 max_vias 3Xyz2 max_vias 3. . .

























결과

목록파일

규칙파일

Bus에 대한 명시적인 개념이 포함되지 않음



• 모델 주도 설계

• 장점

• Bus에 대한 개념이 명확히 드러남

• 테스트가 용이

I imagine that the person who first wrote such a script had only this simple need, and if this werethe only requirement, a script like this would make a lot of sense. But in practice, there are nowdozens of scripts. They could, of course, be refactored to share sorting and string matchingfunctions, and if the language supported function calls to encapsulate the details, the scripts couldbegin to read almost like the summary steps above. But still, they are just file manipulations. Adifferent file format (and there are several) would require starting from scratch, even though theconcept of grouping buses and applying rules to them is the same. If you wanted richerfunctionality 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 theconcept of "bus." Their implementation infers the bus's existence through sorts and stringmatches, but it does not explicitly deal with the concept.

A Model-Driven Design

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

Figure 3.3. A class diagram oriented toward efficient assignment oflayout rules

With these objects implemented in an object-oriented language, the core functionality becomesalmost trivial.

The assignRule() method can be implemented on Abstract Net. The assignedRules() methodon Net takes its own rules and its Bus's rules.

abstract class AbstractNet { private Set rules;

void assignRule(LayoutRule rule) { rules.add(rule); }

Set assignedRules() {

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 assignedRules() { Set result = new HashSet(); result.addAll(super.assignedRules()); result.addAll(bus.assignedRules()); return result; }}

Bus에 대한 개념을 사용

public void testBusRuleAssignment() {Net a0 = new Net("a0");Net a1 = new Net("a1");Bus a = new Bus("a"); 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

Technology