BLOG main image
분류 전체보기 (630)
소프트웨어 개발 (262)
크리스찬 (32)
일반 (297)
자녀교육 (15)
문서, 팁 (3)
나의책읽기 (18)
168,452 Visitors up to today!
Today 20 hit, Yesterday 47 hit
daisy rss
2017.08.15 23:59

목표 시스템은 하나의 메커니즘으로 다양한 이해관계자 간의 계약을 이행한다. 유스케이스는 그 계약에서 행위 부분을 서술한다. 유스케이스를 구성하는 각 문장은 어떤 이해관계자의 이해관계를 보호하거나 증진하는 활동을 서술한다. 그중 한 문장을 살펴보면 두 액터의 상호작용을 서술하거나 이해관계자의 이해관계를 보호하기 위해 시스템이 내부에서 해야 하는 일을 서술한다. 시스템은 정보 수집, 타당성 확인, 로그 갱신 등의 활동을 수행한다.

우선 목표를 가진 액터 간의 상호작용을 파악하는 관점으로 유스케이스를 바라보자. 그런 다음, 이해관계를 가진 당사자 간의 계약으로서의 유스케이스로 논의와 폭을 넓혀갈 수 있다. 


유스케이스를 주의 깊게 마무리하기 위해서, 이해관계자를 모두 나열하고, 유스케이스 수행에 관련한 그들의 이해관계에 이름을 붙인 후, 유스케이스의 성공 수행이 그들에게 가지는 의미와 그들이 시스템으로부터 보증받고자 하는 것을 서술한다. 이것이 끝나면, 유스케이스를 시작하는 순간부터 완료할 때까지 다양한 이해관계를 모두 보증할수 있도록 유스케이스 단계를 작성한다. 

시스템은 합의된 이해관계자의 이해관계를 행동으로 충족시켜야 할 책임이 있다. 행동은 다음 세 가지 유형 중 하나이다.

- 정보를 주고받는 두 액터 간의 상호작용

- 이해관계자 중 한 명의 이해관계를 보호하기 위한 타당성 확인

- 어떤 이해관계자 이해관계를 보호하거나 촉진하기 위한 내부 상태 변화 


성공 시나리오에서 시나리오가 수행할 책임을 가지는 서비스에 대해 이해관계자의 합의된 이해관계를 충족하여야 한다. 실패 시나리오에서 모든 이해관계가 시스템의 보증에 따라 보호된다. 이해관계자의 모든 이해관계가 충족되었거나 보호되었을 때 시나리오는 종료된다. 

`최소보증 - 일차 액터가 목표 달성에 실패했을 때를 대비하여 시스템이 이해관계자와 맺는 최소한의 약속이다. 가장 흔한 최소 보증은 '시스템은 작업이 진행된 곳까지 로그를 남겼다'이다. 

저작자 표시 비영리 변경 금지
신고
Name
Password
Homepage
Secret
2017.08.15 21:40

블록체인은 사회를 바꾸는 핵심 기술이 될 것이다. 

새로운 기술을 도입하려면 먼저 어떤 기술인지 정확히 파악한 후 그 기술로 인해 사업이 어떤 모습으로 바뀌지 생각해봐야 한다. 


블록체인 기술은 서로 분산돼 있는 시스템 환경에서 합의에 의해 거래의 데이터를 분산 복제해서 관리하게 되는 분산원장기술이며, 데이터의 삭제나 조작이 힘든 환경을 제공한다. 이런 특성으로 인해 시스템적으로 신뢰 기반의 투명한 거래 처리가 가능한 비즈니스 네트워크 환경이 가능해진다. 

비트코인은 거래를 블록체인에 등록하고 그것을 P2P 네트워크를 이용한 Prrof of Work라는 작업으로 유지하는 시스템이다. 


대표적인 블록체인 기반 기술

- 비트 코인

비트코인 레퍼런스 

- 이더리움 

분산형 응용프로그램 구축 플랫폼. 전용 프로그래밍 언어로 계약을 기술할 수 있는 것이 특징

- Hyperledger Fabric

리눅스 재단이 주도. 컨소시엄형에 특화된 몇 안되는 블록체인 기반 기술. 공용형의 문제인 PoW의 파이널리티 불확실성을 해결하고, PBFT 등 합의알고리즘으로 교환 가능하며, 속도에도 이점이 있다. 공용형에는 없는 권한형 네트워크(참가자를 한정)를 채택했기 때문에 보다 업무 중심적인 용도로 사용할 수 있다. 

- Corda

R3 컨소시엄 주도로 개발된 금융 분산 원장 기반 기술. 합의형성에 초점을 맞추고 있으며 네트워크 참가자 전원이 모든 데이터를 공유하지 않는 것이 특징 

- Chain Open Standard1

단시간에 거래 완료 상태를 실현하는 새로운 합의 모델과 블록체인 암호화와 같은 기업 사용을 전제로 한 기능을 가짐

- mijin

특정 노드만이 참여할 수 있는 비공개 블록체인을 구축하는 플랫폼으로 트랜잭션 처리의 고속화를 지향함. 합의 알고리즘으로 Proof of Stake를 채택

- Orb1

정기적으로 거래를 확정시켜 결제 완료성을 확보하고 있음. 또한 운영 주체가 슈퍼 피어라는 권한을 부여할 수 있어 중앙 집중 형태와 분산형 모델의 장점을 융햡할 수 있음

- Eris

이더리움에서 파생된 권한형 블록체인. 블록체인을 교환할 수 있는 것이 특징 


블록체인 기술 구성요소

- 피어 투  피어 네트워크 

컴퓨터끼리 같은 목적으로 연결해 네트워크를 형성하는 방식. 어떤 컴퓨터도 같은 처리를 할 수 있기 때문에 1대가 정지해도 시스템 전체에는 영향을 주지 않는 특징을 갖는다. 

- 합의 알고리즘

P2P 네트워크와 같이 정보 도달에 시간차가 있는 분산 네트워크에서 참가자가 하나의 결과에 대한 합의를 얻기 위한 알고리즘이다. 블록체인은 각 노드에서 만든 블록의 정당성을 검토하고 네트워크 전체에서 공유하는 블록체인에 반영하기 위해 이 합의 알고리즘을 사용한다. 

- 전자 서명, 해시 함수

거래를 발생시킨 사람의 정당성을 보증하거나 거래 블록체인 변조 방지, 암호화 등 보안과 관련된 기능이다. 

- 스마트 계약 

블록체인 네트워크에서 동작하는 프로그램. 블록체인 기술 중에서 가장 자유도가 높은 프로그램을 만들 수 있다. 


엔터프라이즈 이용에 있어서의 과제 

첫 번째로 개인 정보의 취급이다. 현재 블록체인에 저장하는 정보를 암호화하면 정보 은닉은 가능하다. 하지만 블록체인의 특성 때문에 정보를 각 노드로 공유하므로 은닉된 정보가 모두에게 전달된다. 더 좋은 성능의 컴퓨터가 등장하거나 암호화 알고리즘의 취약점이 발견된다면 각 노드는 모든 정보를 가지고 있기 때문에 개인 정보가 노출될 수 있다. 따라서 보안 수준이 높은 정보는 블록체인에 저장하지 않거나 정보에 대한 감시를 철저히 해야 한다. 

두 번째로 합의 알고리즘의 선택이다. 신뢰하는 멤버만으로 구성된 네트워크로 구성한다면 이런 부분은 덜 고려해도 상관없다. 

세 번째로 시스템 운영에 있어서의 과제다. 장애 허용 대수를 검토해야 한다.

네 번째로 스마트 계약 등의 버그 수저오가 업데이트 방법이다. 스마트 계약은 미리 설정한 값을 갱신하는 것은 쉬우나 새로운 기능 추가나 기존 프로그램 수정은 어렵다는 문제가 있다. 



이더리움

클라이언트 설치 

Go 언어로 개발된 go-ethereum(geth)가 가장 업데이터 빈도가 높다. 설치 방법은 리눅스의 apt-get 명령을 사용할 수도 있고, 소스 코드를 다운로드받아 직접 컴파일해 설치할 수도 있다. 

테스트 네트워크 구축

mkdir eth_data

geth --networkid "123" --datadir "eth_data" --olympic console

계좌 생성

personal.newAccount("testuser1")

personal.newAccount("testuser2")

계좌 확인 

eth.accounts

잔고 확인 - 잔고는 Wei로 표시 된다. 

eth.getBalance(eth.accounts[0])

블록 수 확인 

eth.blockNumber

채굴 

miner.start()

miner.stop()

송금 - 계좌의 암호를 묻는다 - testuser1 입력

eth.sendTransaction({from:<계좌>, to: <계좌>, value: web3.toWei(1, "ether)})

미확정 트랜잭션 확인

eth.pendingTransactions

송금 확인 

eth.getBalance(eth.accounts[1])

geth 정지 

exit 


Contract를 활용한 응용프로그램

이더리움은 에이전트 방식으로 동작하는 Contract라는 프로그램(스마트계약)을 블록체인에 배치할 수 있고 동작도 자유롭게 프로그래밍할 수 있다. Contract는 계정과 동일한 주소를 가지며 그 주소에 트랜잭션을 발행해 다양한 동작을 수행할 수 있다. Contract는 EVM이라는 가상환경에서 동작한다. Contract 본체는 블록체인에 저장돼 네트워크를 통해 전파되므로 프로그램을 각 실행 환경에 명시적으로 배포할 필요가 없다. 이런 기능을 통해 이더리움은 분산 응용프로그램 기술을 실현한다. 

Contract 프로그래밍은 Solidity라는 이더리움 고유 언어를 사용한다. geth는 JSON-RPC 서버라는 기능이 있어 브라우저에서 HTTP 통신으로 Contract를 조작하거나 블록체인의 다양한 정보를 취득할 수 있다. 

Contract 코딩과 컴파일 및 실행, 블록체인으로 배포 가능한 brower-solidity를 사용해서 개발환경을 구성한다. 

brower-solidity 기동 

최초로 실행하면 Ballot이라는 Contract가 보인다. 새로 Contract를 생성하기 위해 Ballot을 삭제한 뒤 코드를 입력한다. 

Contract 프로그래밍

Contract 배포 

JSON-RPC 서버를 기동하기 위해 다음과 같은 옵션으로 geth를 실행한다. 

geth --networkid "123" --rpc --rpcadd "192.168.56.105" --rpcport 8545 --rpccorsdomain "*" --rpcapi "net,eth,web3,personal" --datadir "eth_data" --olympic console

miner.start() 실행 

brower-solidity 화면에서 Web3 Provider 옵션 선택, Web3 Provider Endpoint 입력란에 geth 콘솔을 기동했을 때 지정한 포트번호와 IP 주소를 입력하고 Create 버튼을 클릭한다. 

테스트 데이터를 입력하고 테스트해 본다. 

JSON-RPC와 연동되는 웹 애플리케이션을 작성할 수 있다. 


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

1부. Putting the Domain Model to Work

A model is a selectively simplified and consciously structured form of knowledge. An appropriate model makes sense of information and focuses it on a problem.

Crunching Knowledge - It is the creativity of brainstorming and massive experimentation, leveraged through a model-based language and disciplined by the feedback loop through implementation, that makes it possible to find a knowledge-rich model and distill it. This kind of knowledge crunching turns the knowledge of the team into valuable models. Knowledge crunching is an exploration, and you can't know where you will end up. 

Communication and the Use of Language - A project needs a common language that is more robust than the lowest common denominator. With a conscious effort by the team, the domain model can provide the backbone for that common language(UBIQUITOUS LANGUAGE), while connecting team communication to the software implementation. That language can be ubiquitous in the team's work.

One of the best ways to refine a model is to explore with speech, trying out loud various constructs from possible model variations. 

Play with the model as you talk about the system. Describe scenarios out loud using the elements and interactions of the model, combining concepts in ways allowed by the model. Find easier ways to say what you need to say, and then take those new ideas back down to the diagrams and code.

MODEL-DRIVEN DESIGN - The effectiveness of an overall design is very sensitive to the quality and consistency of finegrained design and implementation decisions. With a MODEL-DRIVEN DESIGN, a portion of the code is an expression of the model; changing that code changes the model. Programmers are modelers, whether anyone likes it or not. So it is better to set up the project so that the programmers do good modeling work.



2부. The Building Blocks of a Model-Driven Design

Associations, Entities

Value Objects - This involves making choices about copying, sharing, and immutability.

Service - There are important domain operations that can't find a natural home in an ENTITY or VALUE OBJECT. Some of these are intrinsically activities or actions, not things, but since our modeling paradigm is objects. The name service emphasizes the relationship with other objects. Unlike ENTITIES and VALUE OBJECTS, it is defined purely in terms of what it can do for a client. A SERVICE tends to be named for an activity, rather than an entity—a verb rather than a noun. Parameters and results should be domain objects. The interface is defined in terms of other elements of the domain model. The operation is stateless.

Modules (a.k.a. Packages) - There is a limit to how many things a person can think about at once (hence low coupling). Incoherent fragments of ideas are as hard to understand as an undifferentiated soup of ideas (hence high cohesion).

Like everything else in a domain-driven design, MODULES are a communications mechanism. The
meaning of the objects being partitioned needs to drive the choice of MODULES. When you place
some classes together in a MODULE, you are telling the next developer who looks at your design to
think about them together. If your model is telling a story, the MODULES are chapters.

Modularity becomes more critical as the design gets bigger and more complex.

Every object has a life cycle. They go through changes of state to which invariants apply. 

The challenges fall into two categories.
- Maintaining integrity throughout the life cycle
- Preventing the model from getting swamped by the complexity of managing the life cycle

Aggregates - An AGGREGATE is a cluster of associated objects that we treat as a unit for the purpose of data changes. Each AGGREGATE has a root and a boundary. The boundary defines what is inside the AGGREGATE. The root is a single, specific ENTITY contained in the AGGREGATE. The root is the only member of the AGGREGATE that outside objects are allowed to hold references to, although objects within the boundary may hold references to each other. ENTITIES other than the root have local identity, but that identity needs to be distinguishable only within the AGGREGATE, because no outside object can ever see it out of the context of the root ENTITY.

Now, to translate that conceptual AGGREGATE into the implementation, we need a set of rules to apply to all transactions.

- 루트 엔티티는 전역 식별성을 갖고, invariants를 checking할 책임을 갖는다. 경계내에 있는 엔티티는 AGGREGATE내에서만 고유하면 되는 지역 식별성을 갖는다. 경계 밖에서는 루트 엔티티에 대해서만 참조할 수 있다. 루트 엔티티가 내부 엔티티에 대한 참조를 다른 객체에 넘겨줄 수는 있지만 이것은 일시적이고 참조를 넘겨받은 객체는 참조를 보유하지는 않는다. AGGREGATE내의 객체들은 다른 루트 엔티티에 대한 참조만 가질 수 있다. 

- 데이터베이스 질의를 하면 루트 엔티티만 직접적으로 얻을 수 있다. 다른 객체는 모두 루트 엔티티를 통해서 얻을 수 있다. 

- 루트 엔티티가 삭제되면 경계 내의 모든 객체가 삭제된다. 경계내의 어떤 객체에 대한 변경이 committed될 때 AGGREGATE의 모든 invariants가 만족되어야 한다.

Factories - 조립과 같은 방법으로 AGGREAGTE를 생성해야 할 때 FACTORY 사용, 경계 내 엔티티를 생성할 때는 루트 엔티티에 팩토리 메소드 정의

Repositories - In this domain-driven view of the design, FACTORIES and REPOSITORIES have distinct responsibilities. The FACTORY makes new objects; the REPOSITORY finds old objects. The client of a REPOSITORY should be given the illusion that the objects are in memory. The object may have to be reconstituted (yes, a new instance may be created), but it is the same conceptual object, still in the middle of its life cycle.



3부. Refactoring Toward Deeper Insight

The refactorings that have the greatest impact on the viability of the system are those motivated by new insights into the domain or those that clarify the model's expression through the code. It
superimposes another level: refactoring to a deeper model. Executing a refactoring based on domain insight often involves a series of micro-refactorings, but the motivation is not just the
state of the code. Rather, the micro-refactorings provide convenient units of change toward a
more insightful model.

In addition to facilitating change, a supple design contributes to the refinement of the model
itself.


Making Implicit Concepts Explicit 

Digging Out Concepts - Listen to Language, Scrutinize Awkwardness, Contemplate Contradictions, Read the Book, Try, Try Again

How to Model Less Obvious Kinds of Concepts - Constraints and processes are two broad categories of model concepts that don't come leaping to mind when programming in an object-oriented language, yet they can really sharpen up a design once we start thinking about them as model elements.


Specification - A SPECIFICATION states a constraint on the state of another object, which may or may not be present. It has multiple uses, but one that conveys the most basic concept is that a SPECIFICATION can test any object to see if it satisfies the specified criteria.

We might need to specify the state of an object for one or more of these three purposes.
- To validate an object to see if it fulfills some need or is ready for some purpose
- To select an object from a collection (as in the case of querying for overdue invoices)
- To specify the creation of a new object to fit some need

These three uses—validation, selection, and building to order—are the same on a conceptual level.
Without a pattern such as SPECIFICATION, the same rule may show up in different guises, and possibly contradictory forms. The conceptual unity can be lost. Applying the SPECIFICATION pattern

SPECIFICATIONS mesh smoothly with REPOSITORIES, which are the building-block mechanisms for providing query access to domain objects and encapsulating the interface to the database.

An interface of the generator that is defined in terms of a descriptive SPECIFICATION explicitly constrains the generator's products. Building to order can mean creation of an object from scratch, but it can also be a configuration of preexisting objects to satisfy the SPEC.


Supple Design

In a process of constant refactoring, the design itself needs to support change.

Intention-Revealing Interfaces - Name classes and operations to describe their effect and purpose, without reference to the means by which they do what they promise. Write a test for a behavior before creating it, to force your thinking into client developer mode.

Side -Effect-Free Functions - Operations that return results without producing side effects are called functions. A function can be called multiple times and return the same value each time. SIDE-EFFECT-FREE FUNCTIONS, especially in immutable VALUE OBJECTS, allow safe combination of
operations. Complex logic can be done safely in SIDE-EFFECT-FREE FUNCTIONS. 

Assertions - 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. Methods that change system state can be characterized with ASSERTIONS.

Conceptual Contours - Decompose design elements (operations, interfaces, classes, and AGGREGATES) into cohesive units, taking into consideration your intuition of the important divisions in the domain. Observe the axes of change and stability through successive refactorings and look for the underlying CONCEPTUAL CONTOURS that explain these shearing patterns. Align the model with the consistent aspects of the domain that make it a viable area of knowledge in the first place.

The emergence of CONCEPTUAL CONTOURS stabilizes parts of the model and also makes the units more intuitive to use and combine.

Standalone Classes - Both MODULES and AGGREGATES are aimed at limiting the web of interdependencies. Even within a MODULE, the difficulty of interpreting a design increases wildly as
dependencies are added.

Every dependency is suspect until proven basic to the concept behind the object. This scrutiny
starts with the factoring of the model concepts themselves. Then it requires attention to each
individual association and operation. Model and design choices can chip away at dependencies—often to zero. The goal is not to eliminate all dependencies, but to eliminate all nonessential ones.

Try to factor the most intricate computations into STANDALONE CLASSES, perhaps by modeling VALUE OBJECTS held by the more connected classes.

Closure of Operations - The property of closure provides them a way of defining an operation without involving any other concepts. The property of closure tremendously simplifies the interpretation of an operation, and it is easy to think about chaining together or combining closed operations.

Where it fits, define an operation whose return type is the same as the type of its argument(s). 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.

Declarative Design 


분석 패턴이나 디자인 패턴을 적용할 수 있다 - Analysis Patterns are knowledge to draw on. The only requirement is that the pattern should say something about the conceptual domain, not just be a technical solution to a technical problem.



4부. Strategic Design

The world of large system development is not the ideal world. It is necessary to allow multiple models to develop in different parts of the system, but we need to make careful choices about which parts of the system will be allowed to diverge and what their relationship to each other will be. 

A BOUNDED CONTEXT delimits the applicability of a particular model so that team members have a clear and shared understanding of what has to be consistent and how it relates to other CONTEXTS. Integration across the boundaries necessarily will involve some translation, which you can analyze explicitly. 

Having defined a BOUNDED CONTEXT, we must keep it sound. 

CONTINUOUS INTEGRATION means that all work within the context is being merged and made consistent frequently enough that when splinters happen they are caught and corrected quickly. CONTINUOUS INTEGRATION, like everything else in domain-driven design, operates at two levels: the integration of model concepts and the integration of the implementation. 

Institute a process of merging all code and other implementation artifacts frequently, with automated tests to flag fragmentation quickly. Relentlessly exercise the UBIQUITOUS LANGUAGE to hammer out a shared view of the model as the concepts evelove in differenct people's heads. 

Of course, boundaries are special places. The relationships between a BOUNDED CONTEXT and its naighbors require care and attention. 

Code reuse between BOUNDED CONTEXTS is a hazard to be avoided. Integration of fuctionality and data must go through a translation. Name each BOUNDED CONTEXT, and make the names part of the UBIQUITOUS LANGUAGE.

Describe the points of contact between the models, outlining explicit translation for any communication and highlighting any sharing. Map the existing terrain. 

The relationships between BOUNDED CONTEXTS take many forms depending on both design issues and project organizational issues. 

SHRED KERNEL - The goal is to reduce duplication(but not to eliminate it, as would be the case if there were just one BOUNDED CONTEXT) and make integration between the two subsystems relatively easy. 

CUSTOMER/SUPPLIER TEAM - The two subsystems commonly serve very different user communities, who do different jobs, where different models may be useful. The tool set may also be different, so that program code cannot be shared. Eatablish a clear customer/supplier relationship between the two teams. In planning sessions, make downstream team play the customer role to upstream team. Negotiate and budget tasks for downstream requirements so that everyone understands the commitment and schedule. Jointly develop automated acceptance tests that will validate the inface exprected. Add these tests to the upstream tem's test suite, to be run as part of its continuous integration. 

If the quality(upstream team) is not so bad, and the style is reasonably compatible, then it may be best to give up on an independent model altogether. This is the circumstance that calls for a CONFORMIST

CONFORMIST resembles SHARED KERNEL. Where the SHARED KERNEL is a collaboration between two teams that coordinate tightly, CONFORMIST deals with integration with a team that is not interested in collaboration. 

Eliminate the complexity of translation between BOUNDED CONTEXTS by slavishly adhering to the model of the upstream team. 

ANTICORRUPTION LAYER - We need to provide a translation between the parts that adhere to different models, so that the models are not corrupted with undigested elements of foreign models. 

ANTICORRUPTION LAYER is not a mechanism for sending messages to another system. Rather, it is a mechanism that translates conceptual objects and actions from one model and protocol to another. An ANTICORRUPTION LAYER can become a complex piece of software in tis own right. 

SEPARATE WAYS - Integration is always expensive. Sometimes the benefit is small. Declare a BOUNDED CONTEXT to have no connection to the others at all, allowing developers to find simple, specialized solutions within this small scope.     

Taking SEPARATE WAYS forecloses some options. Although continuous refactoring can eventually undo any decision, it is hard to merge models that have developed in complete isolation. If integration turns out to be needed after all, translation layers will be necessary and may be complex.

OPEN HOST SERVICE - When you find your subsystem in high demand, you need a more flexible approach. Define a protocol that gives access to your subsystem as a set of SERVICES. Open the protocol so that all who need to integrate with you can use it. In some situations, using a well-known PUBLISHED LANGUAGE as the interchange model can reduce coupling and ease understanding. 



Choosing Your Model Context Strategy

Teams have to make decisions about where to define BOUNDED CONTEXTS and what sort of relationships to have between them. In fact, such decisions often involve agreements beyound your own team. Start with a realistic CONTEXT MAP and be pragmatic in choosing transformations. 

Relationship with the External Systems - There are three patterns that can apply here - SEPARATE WAYS(통합이 필요하지 않은 경우), CONFORMIST, ANTICURRUPTION LAYER. If you decide on a CONFORMIST design, you must do it wholeheartely. You restrict yourself to extension only, with no modification of the existing model. When the functionality of the system under design is going to be more involved than an extension to an existing system, you'll really want your own BOUNDED CONTEXT, which means building a translation layer, or even an ANTICORRUPTION LAYER.

The System Under Design - 간단히 하나의 BOUNDED CONTEXT로 설계할 수있다. 팀의 규모가 커지면 CONTINUOUS INTEGRATION이 어려워진다. You may look for a SHARED KERNEL and break off relatively independent sets of functionality into separate BOUNDED CONTEXTS, each with fewer than ten people. If all of the dependencies between two of these go in one direction, you could set up CUSTOMER/SUPPLIER TEAMS. 모델링 노력에 충돌이 생기고, 충돌의 원인을 바꿀 수 없거나 바꾸고 싶지 않다면 SEPARATE WAYS를 따르게 해도 된다. ANTICURRUPTION LAYER를 사용할 수도 있다. 

Deployment - The feasibility of a deplyment plan should feed back into the drawing of the CONTEXT boundaries. 



Distillation

As with many chemical distillations, the separated by-products are themselves made more valuable by the distillation process, but the effort is motivated by the desire to extract that one particularly valuable part, the part that distinguishes our software and make it worth building: the "CORE DOMAIN."

CORE DOMAIN - Boil the model down. Find the CORE DOMAIN and provide a means of easily distinguishing it from the mass of supporting model and code. Bring the most valuable and specialized concepts into sharp relief. Make the CORE small. 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 fulfil the vision of the system. Justify investment in any other part by how it supports the distilled CORE. One way or another, creating distinctive software comes back to a stable team accumulating specialized knowldedge and crunching it into a rich model. No shortcuts. No magic bullets. 

GENERIC SUBDOMAINS - An Off-the-Shelf Solution, A Published Design or Model, An Outsourced Implementation, An In-House Implementation와 같은 방법을 고려해 볼 수 있다. 

DOMAIN VISION STATEMENT - Write a short description (about one page) of the CORE DOMAIN and the value it will bring, the "value proposition."

HIGHLIGHTED CORE - The CORE DOMAIN must be made easier to see. 

COHESIVE MECHANISMS - Partition a conceptually COHESIVE MECHANISM into a separte lightweight framework. Particulary watch for formalisms or well documented categories of algorithms. Expose the capabilities of the framework with an INTENTION-REVEALING INTERFACE. Now the other elements of  the domain can focus on expressing the problem("what"), delegating the intricacies of the solution("how") to the framework. 

There is a separation of responsibilites: The model of the CORE DOMAIN or a GENERIC SUBDOMAIN formulates a fact, rule, or problem. A COHESIVE MECHANISMS resolves the rule or completes the computation as specified by the model. 

SEGREGATED CORE - Refactor the model to separate the CORE concepts from supporting players (including ill-defined ones) and strengthen the cohesion of the CORE while reducing its coupling to other code. Factor all generic or supporting elements into other objects and place them into other packages, even if this means refactoring the model in ways that separate highly coupled elements. 

ABSTRACT CORE - When there is a lot of interaction between subdomains in separate MODULES, either many references will have to be created between MODULES, which defeats much of the value of the partitioning, or the interaction will have to be made indirect, which makes the model obscure. Identify the most fundamental concepts in the model and factor them into distinct classes, abstract classes, or interfaces. Design this abstract model so that it expresses most of the interaction between significant components. Place this abstract overall model in its own MODULE, while the specialized, detailed implementation classes are left in their own MODULES defined by subdomain. 



Lage-Scale Structure 

In a large system without any overarching principle that allows elements to be interpreted in terms of their role in patterns that span the whole design, developers cannot see the forest for the trees. 

A "large-scale structure" is a language that lets you discuss and understand the system in broad strokes. A set of high-lkevel concepts or rules, or both, establishes a pattern of design for an entire system. This organizing principle can guide design as well as aid understanding. It helps coordinate independent work because there is a shared concept of the big picture: how the roles of various parts shape the whole. 

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.

Although a lot of work has been done on techincal architecture for software systems, little has been published on the structuring of the domain layer. 

A SYSTEM METAPHOR is a loose, easily understood, large-scale structure that it is harmonious with the object paradigm. 

RESPONSIBILITY LAYERS - Look at the conceptual dependencies in your model and the varing rates and sources of change of different parts of your domain. If you identify natural strata in the domain, cast them as broad abstract responsibilities. These responsibilities should tell a story of the high-level purpose and design of your system. Refactor the model so that the responsibilities of each domain object, AGGREGATE, and MODULE fit neatly within the respoinsibility of one layer. 

It isn't always necessary to start from scratch i ndefining layers for each new model. Certain layers show up in whole families of related domains - Potential(다른 이름으로 Capability), Operation, Policy, Decision. 

Potential - What can be done? Never mind what we are plaaning to do. What could we do? 조직의 자원(사람을 포함한)자원이 organized되는 방법이 핵심 

Operation - What is beign done? What have we managed to make of those potentials? Like the Potential layer, this layer should reflect the reality of the situation, rather than what we want it to be. In this layer we are trying to see our own efforts and activities.

Decision Support - What action shold be taken or what policy should be set? This layer is for analysis and decision making. 

Policy - What are the rules and goals? Rules and goals are mostly passivie, but constrain the behavior in other layers. Designing these interactions can be subtle. Sometimes a Policy is passed in as an argument to a lowe level method. Sometimes the STRATEGY pattern is applied. Policy works well in conjuction with a Decision Support layer, which provides the means to seek the goals set by Policy, constraned by the rules set by Policy. 

Commitment - what have we promised? This layer has the nature of Policy, in that it states goals that direct future operations, but it has the nature of Operations in that commitments emerge and change as a part of ongoing business activity. 

레어어 예) Decision Support -Policy-Operation-Potential, Decision Support -Policy-Commitment -Operation-Potential

KNOWLEDGE LEVEL - A KNOWLEDGE LEVEL is a group of objects that describes how an other group of objects should behave. 지식레벨에 ThingType이 있고, ThingType은 Some Knowledge와 Behavioral Strategy와 연관된다. 운영레벨에는 Thing이 있고, ThingType과 연관된다. 

Create a distinct set of objects that can be used to describe and constrain the structure and behavior of the basic model. Keep these concerns separate as two levels, one very concrete, the other reflecting rules and knowledge that a user or superuser is able to customize.

This is done by splitting the software into a base level, which carries the operational responsibility for the application, and a meta level, which represents knowledge of the structure and behavior of the software. 

PLUGGABLE COMPONENT FRAMEWORK - Distill an ABSTRACT CORE of interfaces and interactions and create a framework that allows diverse implementations of those interfaces to be freely substituted. Likewise, allow any application to use those components, so long as it operates strictly through the interfaces of the ABSTRACTION CORE. 



Conclusion

Even so, any project committed to domain-driven design will be recognizable in a few ways. The defining chracteristic is a priority on understanding the target domain and incorporating that understanding into the software. Everything else flows from that premise. Team members are conscious of the use of language on the project and cultivate its refinement. They are hard to satisfy with the quality of the domain model, because they keep learning more about the domain. They see continuous refinement as an opportunity and an ill-fitting model as a risk. They take design skill seriously because it isn't easy to develop production-quality software that clearly reflects the domain model. They stumble over obstacles, but they hold on to their principles as they pick themselves up and continue forward. 

The core fact that creating good software is a learning and thinking activity. 







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

티스토리 툴바