下载  >  开发技术  >  Java  > Domain Driven Design by Eric(有目录版)

Domain Driven Design by Eric(有目录版) 评分

是的,不管你承认与否,很多时候,我们都是操着面向对象的语言干着面向过程的勾当。面向对象不仅是一个语言,更是一种思维方式。在我们追逐云计算、深度学习、区块链这些技术热点的时候,静下心来问问自己我们是不是真的掌握了OOD;在我们强调工程师要具备业务Sense,产品Sense,数据Sense,算法Sense,XXSense的时候,是不是忽略了对工程能力的要求。据我观察大部分工程师(包括我自己)的OO能力还远没有达到精通的程度,这种OO思想的缺乏主要体现在两个方面,一个是很多同学不了解SOLID原则,不懂设计模式,不会画UML图,或者只是知道,但从来不会运用到实践中;另一个是不会进行领域建模,关于领域
Crunching Knowledge 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 and am- biguities in their terminology and differences between their technical opinions, and they learned They began to explain things more precisely and consistently, and we started to develop a model together Expert 1: It isnt 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 we use 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 to only one net? Expert 1: Yes, thats right Expert 2: Also, every net has a topology, an arrangement that determines the way the elements of the net connect Developer: OK, how about this? opponent ← Instance Pin Net 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 of problems in the design. Developer: I understand how the signal gets carried by the Net to all the pins attached, but how does 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 cant 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 the component from certain Pins to certain others Developer: Something like this? With considerable trial-and-error, together we sketched out a scenario. I Crunching Knowledge Fashe B,→B2 ushd) B.|→B3 w B2 WP sigma) Pin B L signal dO Pin Bs Pin A sIgna Pin C 2 in B4 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 or three hops. It's a rule of thumb. If the path is too long the signal may not arrive during the clock cycle Developer: More than three hops.... So we need to calculate the path lengths. And what counts as 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 民|→>B2 B|→B3 puSh( B2 ghali) wet D. signal)yin B. B PiA!}etx长wD Pin.2 m 5. 4 Developer: The only part that isn t clear to me is where the"pushes"come from. Do we store that 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 every in- stance? Crunching Knowledge gtcL CowP Map C pu shes l723 type B 2→24 getPushesFYowPinNumbev(D) CoWp st b 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 those features And so it went(with much more stumbling than is shown here). Brainstorming and refining; ques tioning and explaining The model developed along with my understanding of the domain and their understanding of how the model would play into the solution. a class diagram representing that early model looks something like this Component Type getPushes From Pin Number(int) Component Pin Net Instance signal(int) signal(int) signal(int) After a couple more part-time days of this, I felt I understood enough to attempt some code. I wrote a very simple prototype, driven by an automated test framework. I avoided all infrastructure. There was no persistence, and no user interface(UI). This allowed me to concentrate on the behavior. I was able to demonstrate a simple probe simulation in just a few more days. although it used dummy data and wrote raw text to the console, it was nonetheless doing the actual computation of path lengths using Java objects. Those Java objects reflected a model shared by the domain experts and myself Crunching Knowledge The concreteness of this prototype made clearer to the domain experts what the model meant and how it related to the functioning software. From that point, our model discussions became more nteractive, as they could see how i incorporated my newly acquired knowledge into the model and then into the software. And they had concrete feedback from the prototype to evaluate their own thoughts Embedded in that model, which naturally became much more complicated than the one shown here, was knowledge about the domain of PcB relevant to the problems we were solving. It consolidated many synonyms and slight variations in descriptions. It excluded hundreds of facts that the engi- neers understood but that were not directly relevant, such as the actual digital features of the com- ponents. a software specialist like me could look at the diagrams and in minutes start to get a grip on what the software was about. He or she would have a framework to organize new information and learn faster, to make better guesses about what was important and what was not, and to com- municate better with the PCB engineers As the engineers described new features they needed, I made them walk me through scenarios of how the objects interacted. When the model objects couldn t carry us through an important scenario, we brainstormed new ones or changed old ones, crunching their knowledge We refined the model the code coevolved. A few months later the PCB engineers had a rich tool that exceeded their expectations Ingredients of Effective Modeling Certain things we did led to the success I just described 1. Binding the model and the implementation. That crude prototype forged the essential link early, and it was maintained through all subsequent iterations 2. Cultivating a language based on the mode At first, the engineers had to explain elementary PCB issues to me, and I had to explain what a class diagram meant. But as the project pro ceeded, any of us could take terms straight out of the model, organize them into sentences consistent with the structure of the model, and be un-ambiguously understood without trans lation 3. Developing a knowledge-rich model The objects had behavior and enforced rules. The model wasn t just a data schema; it was integral to solving a complex problem. It captured knowledge of various kinds 4. Distilling the model Important concepts were added to the model as it became more com- plete, but equally important, concepts were dropped when they didn 't prove useful or central When an unneeded concept was tied to one that was needed a new model was found that distinguished the essential concept so that the other could be dropped 5. Brainstorming and experimenting. The language, combined with sketches and a brainstorm- ing attitude, turned our discussions into laboratories of the model, in which hundreds of ex perimental variations could be exercised, tried, and judged As the team went through sce narios, the spoken expressions themselves provided a quick viability test of a proposed model as the ear could quickly detect either the clarity and ease or the awkwardness of expression 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 Crunching Knowledge Knowledge Crunching Financial analysts crunch numbers. they sift through reams of detailed figures, combining and re- combining them looking for the underlying meaning, searching for a simple presentation that brings out what is really important-an understanding that can be the basis of a financial decision Effective domain modelers are knowledge crunchers. they take a torrent of information and probe for the relevant trickle. They try one organizing idea after another, searching for the simple view that makes sense of the mass. Many models are tried and rejected or transformed Success comes in an emerging set of abstract concepts that makes sense of all the detail this distillation is a rigorous expression of the particular knowledge that has been found most relevant Knowledge crunching is not a solitary activity. A team of developers and domain experts collaborate typically led by developers. Together they draw in information and crunch it into a useful form. The raw material comes from the minds of domain experts, from users of existing systems, from the prior experience of the technical team with a related legacy system or another project in the same domain It comes in the form of documents written for the project or used in the business, and lots and lots of talk. Early versions or prototypes feed experience back into the team and change interpretations In the old waterfall method, the business experts talk to the analysts, and analysts digest and ab stract and pass the result along to the programmers, who code the software. This approach fails because it completely lacks feedback. The analysts have full responsibility for creating the model based only on input from the business experts. they have no opportunity to learn from the pro grammers or gain experience with early versions of software Knowledge trickles in one direction but does not accumulate Other projects use an iterative process, but they fail to build up knowledge because they dont abstract Developers get the experts to describe a desired feature and then they go build it. They show the experts the result and ask what to do next. If the programmers practice refactoring, they can keep the software clean enough to continue extending it, but if programmers are not interested in the domain, they learn only what the application should do, not the principles behind it. Useful software can be built that way, but the project will never arrive at a point where powerful new features unfold as corollaries to older features Good programmers will naturally start to abstract and develop a model that can do more work. But when this happens only in a technical setting, without collaboration with domain experts, the con cepts are naive That shallowness of knowledge produces software that does a basic job but lacks a deep connection to the domain expert' s way of thinking The interaction between team members changes as all members crunch the model together. the constant refinement of the domain model forces the developers to learn the important principles of the business they are assisting, rather than to produce functions mechanically. The domain experts often refine their own understanding by being forced to distill what they know to essentials, and they come to understand the conceptual rigor that software projects require All this makes the team members more competent knowledge crunchers. They winnow out the extraneous. They recast the model into an ever more useful form. Because analysts and program- mers are feeding into it, it is cleanly organized and abstracted so it can provide leverage for the implementation. Because the domain experts are feeding into it, the model reflects deep knowledge of the business. The abstractions are true business principles As the model improves, it becomes a tool for organizing the information that continues to flow through the project. The model focuses requirements analysis. It intimately interacts with program- ming and design. And in a virtuous cycle, it deepens team members 'in-sight into the domain, letting them see more clearly and leading to further refinement of the model. These models are never perfect; they evolve. They must be practical and useful in making sense of the domain. They must be rigorous enough to make the application simple to implement and understand Crunching Knowledge Continuous Learning When we set out to write software, we neverknow enough Knowledge on the project is fragmented scattered among many people and documents, and it's mixed with other information so that we dont even know which bits of knowledge we really need. Domains that seem less technically daunting can be deceiving: we don t realize how much we don' t know. This ignorance leads us to make false assumptions Meanwhile, all projects leak knowledge. People who have learned something move on. Reorgani- zation scatters the team, and the knowledge is fragmented again. Crucial subsystems are out sourced in such a way that code is delivered but knowledge isnt. And with typical design ap proaches, the code and documents don t express this hard-earned knowledge in a usable form, so when the oral tradition is interrupted for any reason, the knowledge is lost Highly productive teams grow their knowledge consciously, practicing continuous /earning(Keriev- sky 2003). For developers, this means improving technical knowledge, along with general domain modeling skills(such as those in this book). But it also includes serious learning about the specific domain they are working in These self-educated team members form a stable core of people to focus on the development tasks that involve the most critical areas. (For more on this, see Chapter 15. )The accumulated knowledge in the minds of this core team makes them more effective knowledge crunchers At this point, stop and ask yourself a question. Did you learn something about the PCB design process? Although this example has been a superficial treatment of that domain, there should be some learning when a domain model is discussed I learned an enormous amount. I did not learn how to be a PCB engineer. That was not the goal. I learned to talk to PCB experts, understand the major concepts relevant to the application, and sanity-check what we were building In fact, our team eventually discovered that the probe simulation was a low priority for development, and the feature was eventually dropped altogether. With it went the parts of the model that captured understanding of pushing signals through components and counting hops. the core of the appl cation turned out to lie else-where, and the model changed to bring those aspects onto center stage The domain experts had learned more and had clarified the goal of the application.(Chapter 15 discusses these issues in depth Even so, the early work was essential. Key model elements were retained, but more important, that work set in motion the process of knowledge crunching that made all subsequent work effective the knowledge gained by team members, developers, and domain experts alike: the beginnings of a shared language; and the closing of a feedback loop through implementation a voyage of dis- covery has to start somewhere Knowledge-Rich design The kind of knowledge captured in a model such as the PCB example goes beyond "find the nouns Business activities and rules are as central to a domain as are the entities involved; any domain will have various categories of concepts. Knowledge crunching yields models that reflect this kind of insight In parallel with model changes, developers refactor the implementation to express the model, giving the application use of that knowledge It is with this move beyond entities and values that knowledge crunching can get intense, because there may be actual inconsistency among business rules. Domain experts are usually not aware of how complex their mental processes are as, in the course of their work, they navigate all these rules reconcile contradictions, and fill in gaps with common sense. Software can't do this. It is through knowledge crunching in close collaboration with software experts that the rules are clarified fleshed out, reconciled, or placed out of scope Crunching Knowledge Example Extracting a Hidden Concept Let's start with a very simple domain model that could be the basis of an application for booking cargos onto a voyage of a ship Voyage Cargo We can state that the booking application s responsibility is to associate each Cargo with a Voy age, recording and tracking that relationship. So far so good. Somewhere in the application code there could be a method like this public int makcBooking(Cargocargo, Voyage voyage Lnt confirmation orderConfirmationsequence next() voyage. adacargo(cargo, confirmaTion)i return confirmation Because there are always last-minute cancellations, standard practice in the shipping industry is to accept 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. In other cases complex rules are applied, favoring major customers or certain kinds of cargo This is a basic strategy in the shipping domain that would be known to any businessperson in the shipping 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 Voyage Cargo capacity sIze public int makeBooking(Cargo cargo, Voyage voyage)i double maxBooking voyage capacity(*1.1i if ((voyage. bookedCargosize()+ cargo size())> maxBooking) return -l int corfirmation-orderConfirmationSequencenext() voyage. addCargo(cargo, confirmation)i return confirmation Now an important business rule is hidden as a guard clause in an application method. Later, in Chapter 4, we ll look at the principle of LAYERED ARCHITECTURE, which would guide us to move the over-booking rule into a domain object, but for now let's concentrate on how we could make this knowledge more explicit and accessible to everyone on the project. This will bring us to a similar solution 1. As written, it is unlikely that any business expert could read this code to verify the rule, even with the guidance of a developer Crunching Knowledge 2. It would be difficult for a technical, non-businessperson to connect the requirement text with the code 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 is usually motivated by the need to substitute different rules, which is not needed here, as far as we know. But the concept we are trying to capture does fit the meaning of a policy, which is an equally important motivation in domain-driven design (See Chapter 12, "Relating Design Patterns to the Model. Voyage Cargo capacity size (sum(cargo size)< voyage. capacity *1.11 Overbooking Polic y The code is now public int makeBooking(Cargo cargo, yoyage voyage)t if (!overbookingPolicy isAllowed(cargo, voyage))return -1 nt confirmation orderConfi rmat sequence. next(l voyage. addcargo(cargo, confirmation)i cturn confirmation The new Overbooking policy class contains this method V turn (cargosize()+ voyage. boo kedcargoSize())<= voyage. capacity()* 1. 1)i It will be clear to all that overbooking is a distinct policy, and the implementation of that rule is explicit and separate Now, / am not recommending that such an elaborate design be applied to every detail of the do- main Chapter 15, Distillation, goes into depth on how to focus on the important and minimize or separate everything else. This example is meant to show that a domain model and corresponding design can be used to secure and share knowledge. The more explicit design has these advantages 1. In order to bring the design to this stage, the programmers and everyone else involved will have come to understand the nature of overbooking as a distinct and important business rule, not just an obscure calculation 2. Programmers can show business experts technical artifacts, even code, that should be intel- ligible to domain experts(with guidance), thereby closing the feedback loop

...展开详情
所需积分/C币:10 上传时间:2017-12-16 资源大小:4.49MB
举报 举报 收藏 收藏 (1)
分享 分享

评论 下载该资源后可以进行评论 1

beautiful5200 这个英文看不懂,又下了一个中文的
2019-11-27
回复
Domain Driven Design(领域驱动设计)

Domain Driven Design(领域驱动设计) 本资源转载自网络,如有侵权,请联系csdn管理员删除

立即下载
Domain Driven Design(DDD) by Eric Evans 领域驱动设计

中文书很难懂,看英文的吧! 本书是领域建模的集大成者。 不仅有很多建模方法和技巧,而且是解决软件复杂性问题的。

立即下载
Domain Driven Design with Spring Boot

Domain Driven Design with Spring Boot epub version

立即下载
Implementing Domain-Driven Design 无水印原版pdf

Implementing Domain-Driven Design 英文无水印原版pdf pdf所有页面使用FoxitReader、PDF-XChangeViewer、SumatraPDF和Firefox测试都可以打开 本资源转载自网络,如有侵权,请联系上传者或csdn删除 查看此书详细信息请在美国亚马逊官网搜索此书

立即下载
Domain-Driven Design

此书是领域驱动设计的开山之作,其后讲的领域驱动设计基本都是基于这本书的。

立即下载
Implementing Domain-Driven Design PDF高清含书签

简介:领域驱动设计方面的权威著作! 作者:Vaughn Vernon 书名:Implementing Domain-Driven Design 特点: PDF高清含书签

立即下载
Domain Driven Design领域驱动设计.pdf

Domain Driven Design领域驱动设计.pdf

立即下载
《领域驱动设计:软件核心复杂性应对之道》(Domain-Driven Design) 中文版PDF (免费)

《领域驱动设计:软件核心复杂性应对之道》Domain-Driven Design: Tackling Complexity in the Heart of Software 1st Edition by Eric Evans 1 edition (August 30, 2003) 译者: 赵俐 / 盛海艳 / 刘霞 出版社: 人民邮电出版社 出版年: 2010-11 页数: 369 《领域驱动设计:软件核心复杂性应对之道》是领域驱动设计方面的经典之作。全书围绕着设计和开发实践,结合若干真实的项目案例,向读者阐述如何在真实的软件开发中应用领域驱动设计。书中给出了领域驱动设计的系统化方法,并将人们

立即下载
Domain-Driven Design in PHP 无水印pdf

Domain-Driven Design in PHP 英文无水印pdf pdf所有页面使用FoxitReader和PDF-XChangeViewer测试都可以打开 本资源转载自网络,如有侵权,请联系上传者或csdn删除 本资源转载自网络,如有侵权,请联系上传者或csdn删除

立即下载