BLOG main image
분류 전체보기 (344)
NWC Consulting (1)
서비스 (173)
출판 (169)
일반 (0)
200,270 Visitors up to today!
Today 26 hit, Yesterday 50 hit
daisy rss
'DDD세미나'에 해당되는 글 26건
2010.04.14 18:48

결론 부분은 이대엽씨가 번역해 주셨습니다. 
번역 내용을 세미나 참석자들에게 공유하는 것으로 세미나를 마무리합니다.

지난해 10월에 시작해서 6개월의 시간이 흘렀습니다. 온라인으로 진행했기 때문에 오프라인 세미나보다 짧은 시간에 세미나를 마무리할 것으로 예상했는데 예상보다 많은 시간이 요구되었던 세미나였습니다.

우리가 Domain-Driven Design를 세미나 주제로 선정한 이유는 다음과 같습니다. 
1. Domain-Driven Design은 세미나로 다룰 만한 가치가 있는 책입니다.
도메인 모델이 문서가 아니라 직접 구현되는 것임을 보여줌으로 다시 한 번 모델의 중요성을 일깨워 줍니다. 
중요한 설계기법들을 구체적인 설계 예와 코드로 제공합니다. 
Domain-Driven Design 개념을 구현하려는 다양한 시도들이 있고, 이들을 사용할 수 있습니다.
번역서가 없고 분량도 만만치 않아서 혼자 공부하기 어려워하는 분들을 돕기 위해서입니다.
2. RSMer(Real Software Modeling을 하는 사람들)들에게 다양한 SW모델링 방법들을 접할 수 있도록 하고, Real Software Modeling이 얼마나 우수한지를 비교할 수 있는 기회를 주기위해서 입니다.

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2010.04.14 18:48
The three basic principles of strategic design (context, distillation, and large-scale structure) are not substitutes for each other; they are complementary and interact in many ways.

전략은 모든 팀들에게 알려져야 합니다. 또한 모든 팀들이 따라야 합니다. (Decisions must reach the entire team) 
소프트웨어 개발의 불확실성은 시간이 갈 수록 시행착오를 겪을 수록 더 많은 더 정확한 정보를 얻을 수 있습니다. 이에 따라 전략도 진화되어야 합니다. (The plan must allow for evolution)
시간이 지나가고 시행착오만 겪는다고 해서 정보가 얻어지는 것이 아닙니다. 지속적인 피드백을 얻을 수 있어야 합니다. (The decision process must absorb feedback)
전략을 결정하는 것이 중요한 일이기는 하나 실력있는 개발자들을 모두 아키텍처팀에 두면 안됩니다. (Architecture teams must not siphon off all the best and brightest)
정작 중요한 애플리케이션은 설계 기술이 부족하고 심지어 설계을 따르지도 못하는 개발자들에 의해 개발되게 됩니다. 아키텍처 팀을 기술만 뛰어난 개발자들로만 구성해도 안됩니다. 도메인 전문가를 포함해야 합니다.
우리는 애플리케이션 개발이 목적이지 아키텍처 구축이 목적이 아닙니다. 핵심 도메인에 초점을 맞추고, 설계를 분명하게 하는데 도움이 되는 것에 집중합니다. (Strategic design requires minimalism and humility)
나머지 것은 훌륭하고 멋질 수는 있지만 지나친 것입니다.
전략에 대해서 서로 다른 팀원들이 커뮤니케이션하려면 팀원들은 서로의 일에 대해서 어느정도 알아야 합니다. 팀원들이 프로젝트와 관련된 것을 두루 두루 알 수 있도록 해야 합니다.
(Objects are specialists; developers are generalists)
프레임워크는 아키텍처를 구현으로 강제화할 수 있는 장점을 갖습니다. (The Same Goes for the Technical Frameworks)
그런데 이것은 장점이기도 하지만 단점이 되기도 합니다. 더 쉽고 더 나은 방법이 있더라도 쉽게 바꿀 수 없게합니다. 프레임워크는 바보들을 위한 것이 되어서는 안됩니다(Don't write frameworks for dummies).
저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2010.04.09 19:10
아키텍처링은 개발에 질서를 부여하는 것입니다.
질서는 우상이 되곤 합니다. 질서를 지키는 것에만 촛점이 맞춰집니다. 그 질서가 적당한 것인지, 잘 못된 점은 없는지를 의심하는 것이 죄가 됩니다.

소프트웨어의 특징 중 하나는 불확실성입니다.
불확실한 것의 질서는 evolving(evolving order)할 필요가 있습니다.
Let this conceptual large-scale structure evolve with the application, possibly changing to a completely different type of structure along the way. Don't overconstrain the detailed design and model decisions that must be made with detailed knowledge.

Unfortunately, that evolution means that your final structure will not be available at the start, and that means that you will have to refactor to impose it as you go along. This can be expensive and difficult, but it is necessary. There are some general ways of controlling the cost and maximizing the gain.

The structure is evolving as system complexity increases and understanding deepens. Each time the structure changes, the entire system has to be changed to adhere to the new order. Obviously that is a lot of work.



복잡한 것은 이해를 도울 방법(system metaphor)이 필요합니다. 
When a concrete analogy to the system emerges that captures the imagination of team members and seems to lead thinking in a useful direction, adopt it as a large-scale structure. Organize the design around this metaphor and absorb it into the ubiquitous language. The system metaphor should both facilitate communication about the system and guide development of it. This increases consistency in different parts of the system, potentially even across different bounded contexts. But because all metaphors are inexact, continually reexamine the metaphor for overextension or inaptness, and be ready to drop it if it gets in the way.


레이어 패턴을 사용합니다(responsibility layer).
Combining high-level responsibilities with layering gives us an organizing principle for a system.


기본 모델에 대한 구조와 행위를 기술하고 제약할 필요가 있다면 메타모델을 만듭니다(knowledge level).
Create a distinct set of objects that can be used to describe and constrain the structure and behavior of the basic model.


일반화된 core(abstract core)를 컴포넌트 프레임워크로 구현하고 구체들에서 plug하도록 합니다(pluggable component framework). 


 


RSMer's Page
질서를 우상화하는 것도 문제지만, 의심할 필요가 없는 것까지 의심하는 것도 에너지 낭비입니다. 어떤 것이 의심할 필요가 없는 질서인지를 알아야 합니다.
기본적인 구조적인 질서는 행위, 컬레보레이션, 전체와 부분의 개념을 이해하면 보입니다.

레이어를 책임성에 의한 배치나 변경을 다루기 위한 의존성(dependency, change)만을 강조하는데, 레이어의 또 다른 중요성은 의사결정 영역을 구분한다는데에 있습니다.
아키텍처가 레이어별로 구분되어 명세될 수 있다.   
These layers were not modules or any other artifact in the code. They were an overarching set of rules that constrained the boundaries and relationships of any particular module or object throughout the design, even at interfaces with other systems.

Imposing this order brought the design back to comfortable intelligibility. People knew roughly where to look for a particular function. Individuals working independently could make design decisions that were broadly consistent with each other. The complexity ceiling had been lifted. 

저자는 도메인을 레이어링하는 방법을 shipping예를 가지고 설명합니다.
뭔가 복잡한 작업을 하는 것처럼 보이는데 사실은 핵심원리에 충실하고 있는 것입니다.
RSM에서는 행위를 요구정보와 수행방법과 수행조건으로 구분하고, 이를 storyboard, handler, manager, regulator, validator 컴포넌트로 구분합니다. storyboard는 애플리케이션 영역의 컴포넌트에 해당하니, 나머지 컴포넌트들이 도메인 컴포넌트들이 됩니다. 이들 컴포넌트들의 종류에 따라 레이어를 두면 됩니다.

shipping예에서 좀 의문이 되는 것은 왜 decision이나 policy가 다른 것을 의존하느냐 입니다. decision이나 policy는 수행조건에 해당하는 것으로 요구정보와 수행방법이 의존하는 것입니다.


구체를 보지 않고 일반화할 수 없습니다. 중복을 보지 않고 공통을 찾아낼 수 없습니다. 아니 할 수도 있습니다. 할 필요가 없을 뿐입니다. 
저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2010.04.07 23:37
A system that is hard to understand is hard to change. The effect of a change is hard to foresee.

프로젝트에는 자원의 제약이 있기 때문에, 어떤 부분이 가치있고 우선해야 하는지를 구분할 수 있어야 합니다.
가치있고 우선해야 하는 부분(core domain)은 작고, 중요한 자원이 투입되어야 합니다.
너무나 당연한 이야기이지요. 문제는 항상 당연한 것을 가볍게 여기고 무시하기 때문에 생깁니다.
Apply top talent to the core domain, and recruit accordingly. Spend the effort in the core to find a deep model and develop a supple design—sufficient to fulfill the vision of the system. Justify investment in any other part by how it supports the distilled core.


어디가 가치있고 중요한 부분인지를 어떻게 압니까(distillation)?
누구나 아는 원리 같은 것들(general subdomains)을 core라고 할 수는 없겠지요. 걸러냅니다.
If you need to keep some aspect of your design secret as a competitive advantage, it is the core domain.

연구 프로젝트가 아니라면, 제안요청서에 시스템을 왜 개발하는지에 대한 비전이나 목적이 있을 것입니다(domain vision statement).

core domain을 좀 더 쉽게 볼 수 있도록 하면 좋겠지요(highlighted core).
Any technique that makes it easy for everyone to know the core domain will do. Two specific techniques can represent this class of solutions.
-
Write a very brief document (three to seven sparse pages) that describes the core domain and the primary interactions among core elements.
- Flag the elements of the core domain within the primary repository of the model, without particularly trying to elucidate its role. Make it effortless for a developer to know what is in or out of the core.


문제를 해결하는 방법들에서 일반적인 것들은 걸러냅니다(cohesive mechanisms).
Partition a conceptually cohesive mechanisms into a separate lightweight framework.
Expose the capabilities of the framework with an intention-revealing interface.

These separated mechanisms are then placed in their supporting roles, leaving a smaller, more expressive core domain that uses the mechanism through the interface in a more declarative style.


core domain에서도 중요한 것(core subdomain)이 구분되도록 덜 중요한 것들을 걸러내고 패키징합니다.

일반화합니다.
Consider slicing horizontally rather than vertically. Polymorphism gives us the power to ignore a lot of the detailed variation among instances of an abstract type. If most of the interactions across modules can be expressed at the level of polymorphic interfaces, it may make sense to refactor these types into a special core module.


저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2010.03.16 20:10
4부는 우리의 한계를 인정하는 것으로 시작합니다. 
Total unification of the domain model for a large system will not be feasible or cost-effective.

이번 장에서 이야기하고자 하는 것은 그림 14.1에 요약되어 있습니다.
이 장을 읽는 목표는 그림 14.1을 보고 설명할 수 있는 것으로 합니다.

하나의 모델로 다룰 수 없어 여러개의 모델로 나누어야 한다면 개별 모델의 경계와 모델들 사이의 관계를 분명히 해야 합니다.
bounded context는 개별 모델들이 적용되는 범위를 정의합니다.
context map은 context들과 context들 사이의 관계를 다룹니다.
context map은 context들을 통합하는 역할을 합니다. 
bounded context 이름은 ubiquitous language에 포함됩니다.

context들 사이의 통합은 context map에서 다루는데 contex내에서 통합은 어떻게 해야 할까요? 그 정도는 쉽게 되니까 무시해도 될까요? 그렇지 않습니다.
하나의 모델 내에서의 통합 또한 만만치 않습니다. 모델 내에서의 통합을 위해 continuous integration이 요구됩니다.

분리된 모델들은 다양한 관계를 갖습니다.
어떤 모델들은 서로 공통된 부분(shared kernel)을 갖기도 합니다.
어떤 모델들은 하나가 다른 하나를 사용하는 관계(customer/supplier teams)를 갖기도 합니다.
supplier에 순전히 따라야(conformist) 할 경우도 있습니다. 
supplier에 순전히 따라야 하지만 따르기 어려운 경우도 있습니다. 모델이 weak하거나 프로젝트의 필요에 맞지 않는 레거시 시스템과의 통합과 같은 경우가 이러한 경우입니다. 이러한 경우에는 client와 supplier사이에 중간 매개체 레이어(anticorruption layer)를 둘 수 있습니다. 
통합하는 잇점이 거의 없는 경우에는 아예 분리할 수도(separate ways) 있습니다. 분리된 팀은 독립적인 방식으로 일 할 수 있습니다. 
한 supplier가 여러 client들에서 사용될 경우도 있습니다. 이러한 경우에는 supplier에 접근하도록 서비스들의 집합을 프로토콜로 정의(open host service)할 수도 있습니다. 좀 더 나아가 프로토콜을 표준화(published language)할 수도 있습니다.  


RSMer's Page
지속적 통합의 중요성은 아무리 강조해도 부족하고, 이 장에서 다루기에는 큰 주제입니다.
아래 링크된 책을 읽어보시길 추천합니다.
http://booksummary.tistory.com/6

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2010.03.06 20:40
작던 크던 단순하던 복잡하던 하나의 방법으로 해결할 수 있기를 바라겠지만 사람들이 하는 일은 복잡도를 다룰 만한 수준을 넘어서면 잘 작동하던 것도 동작을 하지 않는 경우가 많습니다. 복잡성을 다룰 방법이 필요합니다.
복잡성을 다루는 대표적인 방법은 분할정복입니다. 분할정복의 문제는 분할해가면서 국지적인 문제에 집중하다보면 전체적인 통합적인 관점에서 얻을 수 있는 잇점들을 잃는다는 것입니다.  

통합적인 관점에서 얻을 수 있는 잇점을 잃지 않으면서 분할정복하려면 평상시처럼 하면 안됩니다. 전략이 필요합니다. 
어떤 전략이 필요할까요?
다룰 만한 적당한 크기로 나누어야 합니다(context).
중요하게 다루어야 할 부분을 찾아야 합니다(distillation).

큰 것을 다루려면 큰 것을 다룰 수 있는 구조가 필요합니다.(large-scale structure)
작은 것만을 사용한다면 의존성에 묻혀버릴 것입니다.

Strategic design principles must guide design decisions to reduce the interdependence of parts and improve clarity without losing critical interoperability and synergy. They must focus the model to capture the conceptual core of the system, the "vision" of the system. And they must do all this without bogging the project down. To help accomplish these goals, Part IV explores three broad themes: context, distillation, and large-scale structure.

...the relationships can still be too confusing without an overarching theme, applying some system-wide design elements and patterns.




RSMer's Page
4부는 크고 복잡한 시스템에 대한 것으로 실제 이런 규모의 프로젝트를 하기 전까지는 그 내용이 와 닿지 않을 수 있습니다. 양적으로도 많기 때문에 내용을 소화하는데 있어서 많은 시간과 노력을 요구합니다. 
4부의 제목처럼 읽는 데에 전략이 필요한 부분입니다.
 
나중에 이 부분의 내용이 필요할 때 참조할 수 있을 정도로만 체크하고, 가벼운 마음으로 빠른 시간에 읽어내는 것을 목표로 합니다.


저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2010.01.19 20:20

11장은 분석 패턴을 어떻게 DDD 프로세스로 통합할 수 있을 것인지에 대해서 다룹니다. 시간이 없으면 그냥 넘어가도 괜찮은 장입니다. 


분석 패턴을 통해 얻을 수 있는 것은 무엇일까요?

When you are lucky enough to have an analysis pattern, it hardly ever is the answer to your particular needs.
Yet it offers valuable leads in your investigation, and it provides cleanly abstracted vocabulary. It should also give you guidance about implementation consequences that will save you pain down the road.

Analysis patterns focus on the most critical and difficult decisions and illuminate alternatives and choices. They anticipate downstream consequences that are expensive if you have to discover them for yourself.


패턴은 널리 이해되고 잘 설명된 용어를 포함하고 있어 여러분이 프로젝트에서 사용하는 단일의 공통언어(유비쿼터스 언어, Ubiquitous Language)를 향상시키는데 도움이 됩니다. 따라서
패턴을 적용할 때 기본 개념을 변경하지 않도록 주의해야 합니다.




RSMer's Page

향후 다양한 종류의 패턴들(분석, 아키텍처, 설계)에 대해서 행위형식화를 하고, 그들의 적합성을 따져보는 기회를 갖도록 해보겠습니다. 


저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2010.01.16 23:49
소프트웨어는 궁극적으로 사용자에게 서비스하는 것이지만 개발자에게도 서비스해야 합니다. 특히 리팩토링을 강조하는 프로세스에서는 특히 그렇습니다.
The ultimate purpose of software is to serve users. But first, that same software has to serve developers. This is especially true in a process that emphasizes refactoring.

유연한 설계(supple design)는 모델 리팩토링을 가능하게 합니다.

리팩토링을 하려면 이해하기 쉬워야 합니다. 
척보면 뭐하는 것인지 알 수 있어야 합니다. 
뭐하는 것인지 알기 위해서 어떻게 했는지 내부를 뒤져야 하는 것은 리팩토링 개발자를 쉽게 지치게 합니다. 또한 내부를 보고 의도를 알아내기 쉽지 않기 때문에 원래 하고자 했던 의도를 왜곡할 수도 있습니다.
인터페이스에 의도가 분명하게 드러난다면 내부를 뒤질 필요가 그 만큼 줄어들 것입니다. 또한 계약에 의한 설계(assertion)를 한다면 계약을 보면 뭐 하는 것인지 쉽게 알 수 있을 것입니다.

뭐하는 것인지 알기 위해서 이곳 저곳을 뒤지고 다녀야 한다면 이해에 대한 부담이 커짐에 따라 리팩토링을 포기하게 됩니다. 
하나를 이해하기 위해서 또 다른 하나를 이해하지 않도록 해야 합니다.

리팩토링을 하려면 하나를 건드렸을 때 그 하나만 영향을 받아야 합니다.
뭘 하나 건드렸는데 이곳 저곳에서 생각지도 않았던 구멍들이 물코처럼 터진다면(side effect)  리팩토링은 불가능합니다.  

의존성은 하나를 이해하기 위해 또 다른 것들에 대한 이해를 요구하고, 하나에 대한 변경으로 다른 것들에 영향을 미치게 만드는 것입니다. 유연한 설계가 되려면 의존성부터 깨부수어야 합니다.


유연한 설계(변화에 안정적인 부분과 변화를 받아들일 부분을 갖는 설계)는 어떻게 만들어지는가?

1. 인터페이스는 의도가 분명하게 드러나게 하라.
In the public interfaces of the domain, state relationships and rules, but not how they are enforced; describe events and actions, but not how they are carried out; formulate the equation but not the numerical method to solve it. Pose the question, but don't present the means by which the answer shall be found.

2. 가능한한 프로그램 로직의 많은 부분을 부작용이 없는 함수로 작성하라. 
Place as much of the logic of the program as possible into functions, operations that return results with no observable side effects. Strictly segregate commands (methods that result in modifications to observable state) into very simple operations that do not return domain information. Further control side effects by moving complex logic into Value Objects when a concept fitting the responsibility presents itself.

Side-Effect-Free-Fuctions, especially in immutable Value Objects, allow safe combination of operations. When a Fuction is presented through an Intention-Revealing Interface, a developer can use it without understanding the detail of its implementation.

3. 계약에 의한 설계(assertion)를 통해 발생가능한 부작용을 명시하라.
계약에 의한 설계에서는 행위를 선행조건(precondition), 후행조건(postcondition), 불변식(invariant)로 명세합니다. 계약에 의한 설계에 대해 좀 더 알고자 한다면 아래 책을 참조합니다.
Meyer, B. 1988. Object-oriented Software Construction. Prentice Hall PTR

Briefly, "post-conditions" describe the side effects of an operation, the guaranteed outcome of calling a method. "Preconditions" are like the fine print on the contract, the conditions that must be satisfied in order for the post-condition guarantee to hold. Class invariants make assertions about the state of an object at the end of any operation. Invariants can also be declared for entire AGGREGATES, rigorously defining integrity rules.

Because Assertions are all in terms of states, rather than procedures, they make tests easy to write. The test setup puts the preconditions in place; then, after execution, the test checks to see if the post-conditions hold.

4. 개념의 경계를 잘 정하라.
저자는 이게 쉽지 않고, 리팩토링을 통해서 가능하다고 합니다.

When successive refactoring tends to be localized, not shaking multiple broad concepts of the model, it is an indicator of model fit.

Encountering a requirement that forces extensive changes in the breakdown of the objects and methods is a message: Our understanding of the domain needs refinement. It presents an opportunity to deepen the model and make the design more supple.

5. 줄일 수 있는 한 의존을 줄여라.
5.1 스탠드어론(standalone) 클래스를 목표로 하라.

Low coupling is a basic way to reduce conceptual overload. A Standalone Class is an extreme of low coupling.

5.2 연산에 닫혀있도록 하라.
자연수는 덧셈에 닫혀있지만 뺄셈에는 닫혀있지 않습니다.
자연수에 자연수를 더한 결과가 반드시 자연수에 포함되지만, 자연수에서 자연수를 뺀 결과가 자연수에 포함되지 않은 것 일수도 있습니다. 자연수는 뺄셈에 대해서 닫혀 있지 않기 때문에 뺄셈에 대해서 이야기 하려면 자연수 뿐 만 아니라 정수에 대해서 이야기 해야 합니다.
클래스도 연산에 닫혀 있지 않다면 연산을 설명하기 위해서 또 다른 클래스가 요구됩니다.

Where it fits, define an operation whose return type is the same as the type of its argument(s). If the implementer has state that is used in the computation, then the implementer is effectively an argument of the operation, so the argument(s) and return value should be of the same type as the implementer. Such an operation is closed under the set of instances of that type. A closed operation provides a high-level interface without introducing any dependency on other concepts.

This pattern is most often applied to the operations of a Value Object. Because the life cycle of an Entity has significance in the domain, you can't just conjure up a new one to answer a question.

6. 도메인을 하위 도메인으로 나누고 다룰 대상을 잘 선정합니다.

7. 수학과 같이 잘 정형화 되었고, 프로젝트 참여자들이 분명한 이해를 갖고 있는 도메인을 참조합니다.




유연한 설계는 클라이언트 코드에서 선언적 스타일의 설계를 사용할 수 있도록 합니다.

A supple design can make it possible for the client code to use a declarative style of design.

위 내용에 앞서 저자는 계약에 의한 설계가 어떤 방식으로 사용되는지를 언급하고 있습니다.
그 내용은 유연한 설계와 별다른 관계가 없어 보이고, 위의 내용을 언급하기 위한 과정 중 소개되는 보너스로 보입니다.

계약에 의한 설계는
테스트에 사용할 수 있습니다. 
코드 생성 방법에 사용할 수 있습니다. 
규칙 기반 프로그래밍에 사용할 수 있습니다.
DSL(domain specific language)과 같은 방식이 될 수도 있습니다.
으로 사용할 수 있습니다.




RSMer's Page

본질이 중요합니다. 
본질은 이해하기는 어려우나 이해하고 나면 당연한 것이 됩니다.
본질은 당연한 것이기에 인간은 본질에 대한 이해에서 출발할 때 복잡한 것을 잘 이해합니다.
본질에서 시작하면 이해하기 쉽기 때문에 그 복잡도와 상관 없이 단순해 보입니다.

당연한 것을 당연한 것으로 알지 않고 시작하면 복잡해집니다. 복잡해지면 그것을 해결할 방법들(패턴들)이 필요합니다. 수많은 반복을 통한 깨달음은 당연한 것을 찾아냅니다. 본질에 가까워진 것입니다.

RSM에서 기존의 개념들을 새로 정의해 가는 이유가 여기에 있습니다. 본질적인 이해를 바탕으로 한 정의에서 단순함이 나오기 때문입니다.

인터페이스는 행위 명세입니다.
행위의 의도가 분명히 드러나도록 한다는 것은
의뢰자가 대리자를 사용해서 달성하고자 하는 목적이 무엇인지(행위이름),
대리자가 의뢰자에게 요청받은 행위수행을 위해 의뢰자로 부터 어떤 것들을 받아야 하는지(요구정보), 
행위수행을 둘러싼 제약사항들은 무엇인지(수행조건)를 명세하는 것입니다. 

RSM에서도 수행조건을 명세하기 위해 계약에 의한 설계 방법을 사용합니다.
RSM에서는 invariant를 type invariant와 behavioral invariant로 좀 더 구분합니다. type invariant는 후행조건을 이루는 상태로 기술됩니다.

객체와 값의 구분, 컬레보레이션과 부분의 구분으로 시작하면 값과 부분이 독립되기 때문에 불필요한 의존을 처음부터 줄일 수 있습니다.
의존이 문제를 복잡하게 만든다고 해서 모든 의존을 없앨 수는 없습니다. 있어야 할 의존이 있어야 할 곳에 있는 것이 중요합니다.

개념에 대한 경계 또한 전체와 부분의 개념과 이들을 등장시키는 정적행위와의 관계를 분명히 알면 쉽게 도출할 수 있습니다.


저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2010.01.16 23:47

9장의 내용은 이대엽씨께서 정리해주셨습니다.
http://decoder.tistory.com/936


implicit한 것이 implicit한 것인지를 알아야 explicit할 수 있습니다.  

리팩토링을 하려면 구린 냄새를 잘 맡아야 합니다. implict한 것들이 풍기는 냄새. 

implicit는 보통 암시적으로 해석됩니다. 이 장에서 implicit는 누락된 것, 모호한 것, 불분명한 것, 모순된 것의 의미를 갖고 있습니다. 
프로젝트 참여자들이 사용하는 언어에 귀를 기울이면 implict한 냄새를 맡을 수 있습니다. 누락된 것, 모호한 것, 불분명한 것, 모순된 것들이 풍기는 냄새입니다.
개념을 explicit하게 하려면 냄새나는 곳을 파면 됩니다.

Listen to the language the domain experts use. Are there terms that succinctly state something complicated? Are they correcting your word choice (perhaps diplomatically)? Do the puzzled looks on their faces go away when you use a particular phrase? These are hints of a concept that might benefit the model.

When the users or domain experts use vocabulary that is nowhere in the design, that is a warning sign. It is a doubly strong warning when both the developers and the domain experts are using terms that are not in the design.

The place to dig is the most awkward part of your design. The place where procedures are doing complicated things that are hard to explain. The place where every new requirement seems to add complexity.

Different domain experts see things different ways based on their experience and needs. Even the same person provides information that is logically inconsistent after careful analysis. Such pesky contradictions, which we encounter all the time when digging into program requirements, can be great clues to deeper models. Some are just variations in terminology or are based on misunderstanding. But there is a residue where two factual statements by experts seem to contradict.


explict한 개념을 얻기 위해 책의 도움을 받을 수도 있습니다.
포기 하지 않고 계속 시도해야 합니다.

There really is no choice, anyway. Experimentation is the way to learn what works and doesn't. Trying to avoid missteps in design will result in a lower quality result because it will be based on less experience. And it can easily take longer than a series of quick experiments.

 


RSMer's Page

수행조건은 선언적 방식 또는 방어적 방식으로 설계될 수 있습니다.
방어적 방식으로 선택될 때 조건에 대한 유효성을 평가하는 검증자와 규칙에 대한 규정자로 구분됩니다.

이 장에서 설명되는 Specification은 다음과 같은 세 가지 목적으로 사용됩니다.
1.
To validate an object to see if it fulfills some need or is ready for some purpose
2.
To select an object from a collection (as in the case of querying for overdue invoices
3.
To specify the creation of a new object to fit some need

1번은 검증자에 해당합니다.
2번과 3번은 규정자에 속합니다. 선택에 대한 규칙과 생성에 대한 규칙입니다.
생성에 대한 규칙은 선행조건 중 요구정보에 대한 조건입니다. 
Specification은 제약사항에 대한 것이기 때문에 행위수행에 대한 규칙은 포함되어 있지 않습니다.
RSM에서의 수행방법 또한 명세에 포함하기 때문에 수행 규칙 또한 포함합니다.
저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2010.01.03 18:13
꾸준한 리팩토링을 통해 얻을 수 있는 것
Our pace of development was accelerating at a stage where most projects are beginning to bog down in the mass and complexity of what has already been built.

꾸준한 리팩토링은 모델링에 있어서의 획기적인 진전(breakthrough)이라는 사건을 가져다 주기도 합니다. 갑자기 도메인에 대한 혜안이 열리는 것입니다.

8장의 내용은 이대엽씨께서 정리해주셨습니다.
http://decoder.tistory.com/935



RSMer's Page

꾸준한 모델 리팩토링은 도메인에 대한 점진적 이해를 가져다 줌으로 어느 순간에 이해에 획기적인 진전을 가져다 줄 수 있습니다.

모델링에 있어서의 획기적인 진전이라는 사건을 꾸준한 모델 리팩토링에만 기대는 것은 위험합니다. 프로젝트는 기간 내에 완료되어야 하는 것으로 획기적인 진전이란 사건은 프로젝트 기간 내에 일어나야 하기 때문입니다. 물론 획기적인 진전이 꾸준한 모델 리팩토링의 부가적인 효과라고 생각한다면 이것은 큰 문제가 되지 않을 수도 있습니다. 

리팩토링은 점진적 진전을 위한 도구입니다.
점진적 진전은 획기적인 진전을 가져올 수 있습니다. 그렇다고 해서 획기적인 진전을 위해 꼭 점진적 진전이 요구되는 것은 아닙니다.


모델링에 있어서도 수준이 있습니다.
어떤 사람의 일상적인 사건이 다른 사람에게는 획기적인 사건일 수 있습니다. 
프로젝트 기간 내에 고품질의 모델을 만들기 위해서는 다른 사람에게 있어서 획기적인 진전이 점진적 진전과 같이 일상적으로 일어날 수 있는 방법이 필요합니다.
RSM의 기본개념과 행위형식화는 도메인에 대한 획기적인 진전이라는 사건이 발생하기까지의 시간을 단축하는 방법들입니다.  

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
prev"" #1 #2 #3 next

티스토리 툴바