官术网_书友最值得收藏!

Chapter 2. Finding the Core Problem

Every piece of software is written to solve a problem, and in turn is a perfectly valid solution for this exact problem. Sadly, the problem a piece of software solves so perfectly is not always the problem the software was created for in the first place or even the problem the programmer had in mind when the software was written. The history of programming is full of examples where developers tried various ways to come up with a way to be able to perfectly state a problem first, and then implement a solution. Developing software based on the waterfall model is a great example of having a nice idea that failed to deliver on the promise. When you ask the parties involved about the failure, the reason will most likely be that the problem diverged from the specification, or the specification was misunderstood in—according to one party—a very obvious way. So, why is this?

When starting a software project, especially one motivated by a business need, we set out to model a part of the real world and apply a set of constraints and algorithms to it, to ease the job of one or more parties involved in the business. The problem is that the party that has the issue the developer is trying to solve is most likely not the developer. This means that the developer first has to get an understanding of what the request really is to actually know what is supposed to be developed.

How can we get a deep enough understanding of a certain part of the business without the (most likely) years of experience our clients have ahead of us? The solution to this, and the most likely problem, is communication. We need to find a way to explore the problem deeply enough, and backed with our knowledge of how to model a world in software, to be able to ask the right questions. We need to do this in such a way we don't lose the non-technical people so that we can draw from their understanding. This comes back to the language mismatch between developers and business people, and it is probably the biggest obstacle to overcome. In domain-driven design, this is referred to as the ubiquitous language of the project, a language shared by all parties involved in the project. Establishing this kind of language allow us to communicated clearly across team boundaries, and as mentioned before, this is one of the core ideas in domain-driven design.

Coming back to our example of the orcs running a dungeon, we don't know how this is done; we don't even completely understand the constraints that cultural aspects involve or apply. The world of the orcs is one in which we are an outsider who can only watch, ask questions, and model it according to our understanding. We naturally have to trust the local experts. Even though we aren't as much of an outsider in real-world problems, we should always try to view the problem from the outside as much as possible because, in a business that has taken years to grow, our own assumptions are probably wrong anyway.

In the following, we are going to explore the problem and introduce a set of tools that will help to do this. We will cover several aspects, but most importantly the following:

  • Using pen and paper for programming
  • Code spikes and throwaway code
  • Mapping our actors out—creating a dependency graph for our domain
主站蜘蛛池模板: 驻马店市| 浪卡子县| 漳州市| 临沭县| 贺兰县| 芜湖县| 全州县| 祁东县| 丰都县| 成都市| 云梦县| 仁寿县| 长寿区| 临武县| 昌邑市| 鹤岗市| 昔阳县| 思茅市| 宜城市| 赣州市| 元氏县| 高雄县| 舞钢市| 康保县| 崇左市| 北票市| 重庆市| 临湘市| 拉孜县| 赣州市| 保山市| 伊春市| 灌南县| 福泉市| 云林县| 寿阳县| 额尔古纳市| 都昌县| 利津县| 灵武市| 永平县|