Vlad Khononov - Learning Domain-Driven Design
Here you can read online Vlad Khononov - Learning Domain-Driven Design full text of the book (entire story) in english for free. Download pdf and epub, get meaning, cover and reviews about this ebook. year: 2021, publisher: OReilly Media, Inc., genre: Home and family. Description of the work, (preface) as well as reviews are available. Best literature library LitArk.com created for fans of good reading and offers a wide selection of genres:
Romance novel
Science fiction
Adventure
Detective
Science
History
Home and family
Prose
Art
Politics
Computer
Non-fiction
Religion
Business
Children
Humor
Choose a favorite category and find really read worthwhile books. Enjoy immersion in the world of imagination, feel the emotions of the characters or learn something new for yourself, make an fascinating discovery.
- Book:Learning Domain-Driven Design
- Author:
- Publisher:OReilly Media, Inc.
- Genre:
- Year:2021
- Rating:3 / 5
- Favourites:Add to favourites
- Your mark:
Learning Domain-Driven Design: summary, description and annotation
We offer to read an annotation, description, summary or preface (depends on what the author of the book "Learning Domain-Driven Design" wrote himself). If you haven't found the necessary information about the book — write in the comments, we will try to find it.
Vlad Khononov: author's other books
Who wrote Learning Domain-Driven Design? Find out the surname, the name of the author of the book and a list of all author's works by series.
Learning Domain-Driven Design — read online for free the complete book (whole text) full work
Below is the text of the book, divided by pages. System saving the place of the last page read, allows you to conveniently read the book "Learning Domain-Driven Design" online for free, without having to search again every time where you left off. Put a bookmark, and you can go to the page where you finished reading at any time.
Font size:
Interval:
Bookmark:
With Early Release ebooks, you get books in their earliest formthe authors raw and unedited content as they writeso you can take advantage of these technologies long before the official release of these titles.
This will be the 2nd chapter of the final book. Please note that the GitHub repo will be made active later on.
If you have comments about how we might improve the content and/or examples in this book, or if you notice missing material within this chapter, please reach out to editor at jleonard@oreilly.com.
Its developers (mis)understanding, not domain experts knowledge, that gets released in production.
Alberto Brandolini
In the previous chapter, we started exploring business domains. You learned how to identify a companys business domains, or areas of activity, and analyze its strategy to compete in them; that is, its business subdomains boundaries and types.
This chapter continues the topic of business domain analysis but in a different dimension: depth. It focuses on what happens inside a subdomain: its business function and logic. You will learn the domain-driven design tool for effective communication and knowledge sharing: the ubiquitous language. Here we will use it to learn the intricacies of business domains. Later in the book we will use it to model and implement their business logic in software.
The software systems we are building are solutions to business problems. In this context, the word problem doesnt resemble a mathematical problem or a riddle that you can solve and be done with. In the context of business domains, problem has a broader meaning. A business problem can be challenges associated with optimizing workflows and processes, minimizing manual labor, managing resources, supporting decisions, managing data, and so on.
Business problems appear both at the business domain and subdomain levels. A companys goal is to provide a solution for its customers problems. Going back to the FedEx example in , that companys customers need to ship packages in limited time frames, so it optimizes the shipping process.
Subdomains are finer-grained problem domains whose goal is to provide solutions for specific business capabilities. A knowledge management subdomain optimizes the process of storing and retrieving information. A clearing subdomain optimizes the process of executing financial transactions. An accounting subdomain keeps track of the companys funds.
To design an effective software solution, we have to grasp at least the basic knowledge of the business domain. As we discussed in , this knowledge belongs to domain experts: its their job to specialize in and comprehend all the intricacies of the business domain. By no means should we, nor can we, become domain experts. That said, its crucial for us to understand domain experts and to use the same business terminology they use.
To be effective, the software has to mimic the domain experts way of thinking about the problemtheir mental models. Without an understanding of the business problem and the reasoning behind the requirements, our solutions will be limited to translating business requirements into source code. What if the requirements miss a crucial edge case? Or fail to describe a business concept, limiting our ability to implement a model that will support future requirements?
As Alberto Brandolini says, software development is a learning process; working code is a side effect. A software projects success depends on the effectiveness of knowledge sharing between domain experts and software engineers. We have to understand the problem in order to solve it.
Effective knowledge sharing between domain experts and software engineers requires effective communication. Lets take a look at the common impediments to effective communication in software projects.
Its safe to say that almost all software projects require the collaboration of stakeholders in different roles: domain experts, product owners, engineers, UI and UX designers, project managers, testers, analysts, and others. As in any collaborative effort, the outcome depends on how well all those parties can work together. For example, do all stakeholders agree on what problem is being solved? What about the solution they are buildingdo they hold any conflicting assumptions about its functional and nonfunctional requirements? Agreement and alignment on all project-related matters are essential to a projects success.
Research into why software projects fail has shown that effective communication is essential for knowledge sharing and project success..
During the traditional software development lifecycle, the domain knowledge is translated into an engineer-friendly form known as an analysis model, which is a description of the systems requirements rather than an understanding of the business domain behind it. While the intentions may be good, such mediation is hazardous to knowledge sharing. In any translation, information is lost; in this case, domain knowledge that is essential for solving business problems gets lost on its way to the software engineers. Furthermore, this is not the only such translation on a typical software project. The analysis model is translated into the software design model: a software design document, which is translated into an implementation model, or the source code itself. As often happens, documents go out of date quickly. The source code is used to communicate business domain knowledge to software engineers who will maintain the project later. illustrates the different translations needed for domain knowledge to be implemented in code.
Such a software development process resembles the childrens game Telephone: the message, or domain knowledge, often becomes distorted. The information leads to software engineers implementing the wrong solution, or the right solution but to the wrong problems. In either case, the outcome is the same: a failed software project.
Domain-driven design proposes a better way to get the knowledge from domain experts to software engineers: by using a ubiquitous language.
Using a ubiquitous language is the cornerstone practice of domain-driven design. The idea is simple and straightforward: if parties need to communicate efficiently, instead of relying on translations, they have to speak the same language.
Although this notion is borderline common sense, as Voltaire said, common sense is not so common. The traditional software development lifecycle implies the following translations:
Domain knowledge into an analysis model
Analysis model into requirements
Requirements into system design
System design into source code
Instead of continuously translating domain knowledge, domain-driven design calls for cultivating a single language for describing the business domain: the ubiquitous language.
All project-related stakeholderssoftware engineers, product owners, domain experts, UI/UX designersshould use the ubiquitous language when describing the business domain. Most importantly, domain experts must be comfortable using the ubiquitous language when reasoning about the business domain; this language will represent both the business domain and the domain experts mental models.
Font size:
Interval:
Bookmark:
Similar books «Learning Domain-Driven Design»
Look at similar books to Learning Domain-Driven Design. We have selected literature similar in name and meaning in the hope of providing readers with more options to find new, interesting, not yet read works.
Discussion, reviews of the book Learning Domain-Driven Design and just readers' own opinions. Leave your comments, write what you think about the work, its meaning or the main characters. Specify what exactly you liked and what you didn't like, and why you think so.