段启超2020-05-26防腐层是模型的一个规范，分享下我对防腐层的认知： 我接触防腐层的概念是从DDD的限界上下文开始的。Eric用细胞膜的概念来解释“限界”的概念，细胞膜只让细胞需要的物质进入细胞，同样，我们的代码之间业务也存在这个样一个界限，同一个对象的业务含义在不同的上下文中是不一样的。以在网上买书为例，在购买页面，我们的关注点在于这本书的名称，作者，以及分类，库存等信息；提交订单后，这本书就成为了订单上下文中的一个订单item，我们会关注这个item 的数量以及购买他的人是谁，以及书的配送地址等； 订单提交给仓库后，仓库会关心这本书还有没有库存，以及打包状态，分拣，物流等状态。 防腐层是在限界上下文之间映射（说白了就是交互）的方式，体现在代码上就是一个对象的转换，这个转换的意义在于隔离变化，防止因为对象在一个上下文中的变化扩散到其他的上下文中。 关于规范： 规范也是团队文化中很重要的一部分，以持续集成为例子，它的执行严格依赖于团队的开发纪律文化，以为了所谓赶进度而单元测试覆盖很低或者直接不写；采用分支策略方开发，一星期都合并不了主干，类似的人到处倒是，也就因为这一点，很多团队都在持续集成这个环节上掉队了。所以开发规范真的很重要，时刻谨记：混乱始于没有规范。展开作者回复: 非常好的补充！
共 5 条评论92
西西弗与卡夫卡2020-05-25业务讨论之后进行领域设计，画出出静态模型（包括子系统、模块等）和动态结构（交互等），或者先勾勒接口（内内外系统的区隔），再做模型。实际过程有很多反复，并且会进行角色代入，看模型能否支持业务，直到模型比较稳定作者回复: 你们做得很好
共 5 条评论36
Ghoul Zhou2020-05-25慢慢的，某个瞬间，突然觉得自己的工作不再是码农，而是软件设计，并且在工作中得到强烈的自我肯定。 一个好的软件设计思路，首先是符合大众习惯行为、符合日常常理，其次再是数据模型设计、技术范畴设计。 一个好的软件设计实现，往往可以很容易兼容正常合理的需求变更，对开发工作来说，掌握其核心，理论与实践相结合，可以事半功倍！作者回复: 你把自己当做码农，你就是码农；你把自己当做优秀的程序员，你就是优秀的程序员。心理学上称之为皮格马利翁效应。
32
光明2020-05-26简单一点的项目，成员相互讨论（主要讨论业务场景和流程），内心会意即可。 复杂一点的项目，设计一般落脚在粒度较粗的文档上，往往也以说明业务流程为主，很少对实现过程中的细节文档化。 所以，我们的项目设计，模型一般会被业务场景和流程替代。文中的「模型」和「规范」，更多取决于工程师了。。。作者回复: 对，你说的确实符合大部分做设计的方式。这种设计的关注点在于实现功能，而非构建模型。 这种做法容易让人忽略掉哪个东西是核心的，是模型，还是流程。流程是容易调整的，而模型如果变了，这个软件整个就变了。做设计的关键是，找到不变的东西。
共 3 条评论16
木云先森2020-05-25还需要前面有个好的产品经理或是业务专家。以及公司有个好的文化。各种频繁的插队的需求，各种前后都无法闭环的需求。都是，软件产品异常大的阻碍作者回复: 《10x 程序员工作法》在先，《软件设计之美》在后。
13
渔夫2020-05-25很多软件产品的需求都是一点点冒出来的，甚至中途需求还会去溜出去绕个弯，然后又回归，设计有种被牵着鼻子走的感觉，工期紧迭代快，结果就是设计的模型中有大量名不符实的定义，还有很多定义的补丁，实在很糟心，当然需求发展方向终会明朗，这时候就需要重构整理，包括设计和实现，同时又要应对新的业务开发，于是形成了两线或多线作战，苦啊！这样的情况除了增加团队，不知道老师有什么好的建议？作者回复: 先去学《10x程序员工作法》，先别让人给自己捣乱，有一个合理的工作计划。如果你没时间学习，没时间做改进，别的东西都不用说了。 有了一个合理的安排之后，才是说要怎么改进，要怎么做得更好，消除欠下的技术债。
共 2 条评论12
迈步2020-06-17老师您好，我们有一套基于DDD思想的程序开发模板，我们为了避免个体开发差异，所以建议大家都使用统一的开发模板。目前我面临着两个问题 1、针对某些使用简单分层架构即可解决问题的服务，是允许使用简单分层架构还是使用统一的DDD开发模板？ 2、统一开发模板在一定程度上规避了个体差异上的劣势。那么个体差异上的优势如何更好的体现呢？作者回复: 把 DDD 当做一个模板，这个理解方式本身是没有问题的，它就是告诉你，如何把设计中的模型分门别类的放置，后面我们讲 DDD，差不多也是这个思路。 对于任何一个系统而言，需求都是一点一点增加的，前期不做设计，后期改动起来，难度就非常大了。所以，核心的点在于，设计要做好，别看它现在简单。分层不是你的设计，而构建出你的模型才是设计。 我不是特别理解你们按照 DDD 思想的开发模板到底是个什么东西，是一个开发框架，还是一个思维工具，所以，不敢妄加判断。 对于一个团队而言，开发的一致性比个性要重要，因为没有人可以保证一直在一个团队工作下去。 如果你真的有不错的理念，去做规范和框架的级别的优化、去做算法上的优化，不要在小的地方体现创造力，意义不大。
10
escray
2020-05-27文章在开篇提出的关于软件设计的问题，其实也是我现在的困惑，因为在做求职前的准备，感觉有很多东西要学，极客时间的专栏那么多，眼花缭乱。如何才能提高自己的求职成功率呢？ 软件开发是为了解决问题，而软件设计就是在需求和解决方案之间的桥梁。 对于“软件设计就是构建出一套模型”这个说法，我感觉似乎有点过于抽象了，虽然文中列举的那个交易系统模型，确实很简洁、准确。 如果单独来看“模型”和“规范（约束）”都比较容易理解，但是如果说软件设计就是设计出模型和规范来，又有些不好理解了。特意去看了一下 Wiki: Software design is the process by which an agent create a specification of a software artifact, intended to accomplish goals, using a set of primitive components and subject to constraints. 感觉上自己以前可能更看重软件开发的结果，而忽视了其中的模型和约束。 在这之前，如果拿到一个项目，大概会先看看是 CS 还是 BS 的，一般会采用 MVC 或者是分层模型，然后再去看看有没有其他的开源软件可以借鉴，之后就开始码程序了，编写代码边修改，可能从整体设计上考虑的比较少。 看了一下留言，发现自己之前可能局限于个体软件作坊，并没有正式或者完整的软件设计过程。那么我有一个问题：软件设计是只适用于相对复杂一些的软件开发过程么？如果程序本身比较简单，而且是那种“用完即焚”式的，是否还需要设计？ 另外一个问题，就是软件设计和架构设计的区别在哪里？应该不仅仅是范围大小的差别吧 。 期待后续的专栏。展开作者回复: 非常感谢你的补充！ 我不会为 Hello，World 做设计，因为它真的“用完即焚”，在开篇词里我说过，设计是应对需求规模的算法。需求越来越多，设计和不设计的差别就会体现出来。但是，你不学习软件设计的话，想直接应对复杂软件是不可能的。 关于软件的设计过程，我们后面会讲到 DDD，你可以关注一下。 软件设计和架构设计，其实是没有区别的，只不过，通常把高层一些的设计称为架构设计，但我们这里所学的设计原则同样适用于架构设计。
10
学习学个屁2020-05-26刚开始按照模型和规范走着，后来随着需求的改动，客户不停的催促，代码改动越来越乱，先把工作完成后再改规范，还是有什么好的办法。作者回复: 首先，要分清楚哪些是人为的问题，哪些是设计的问题。赶工绝对是人为的问题，需要设置正确的预期，这是《10x 程序员工作法》讨论的范畴。 其次，如果是设计问题，需要把分清楚哪些是变的部分，哪些是不变的部分。不变的部分花力气去设计，变的部分需要等一等，等它相对稳定一些，再花大力气去设计。 规范主要是针对你需要花力气去设计的部分，混乱的部分，就先混乱着。让子弹飞一会儿。
共 2 条评论8
小文同学2020-05-25我独立设计的第一个项目整体来说，是失败的。就是盲目模仿前项目，没理解，分层，抽象，接口，模型等设计概念，最终项目陷入很麻烦的技术问题。作者回复: 应该说是独立“实现”了一个项目。
共 2 条评论5