共计 2627 个字符，预计需要花费 7 分钟才能阅读完成。
软件开发架构演变与 DDD 起源
单体服务架构：大略 10 年前，我在武汉工作的时候，甲方客户购买咱们的产品，个别都是连着设施一起购买，一套软件系统，一台惠普或者戴尔的企业级服务器，再加一个彩色的铁盒，销售部能够卖小几百万左右、外加每年维护费用，这就是一个十分典型的单体服务开发、运作的形式。
SOA 服务化、微服务架构：前端开发同学广泛离业务域构造比拟远，个别比拟难真正意义下来了解服务化与微服务，我集体对微服务和 SOA 区别的了解，SOA 服务化，往往偏重某一类具体业务场景下性能的实现，它必须有一个明确的业务场景来做撑持。微服务更加偏重相似区块链这种去中心化构造，它的开发、部署、公布等等能够齐全独立隔离。
中台化架构：中台化除了蕴含 SOA、微服务这个技术构造以外，业务场景层面，它更推崇信息智慧化，大数据、深度学习、神经网络、人工智能，他的原材料可能是用户个体数据信息，但作用后果并不是间接反哺在单个利用个体，而是交给公司经营、市场、供应链等等兄弟平台，兄弟部门来做下一步决策。
中台化最典型的场景是相似金融、保险、电商等行业，我做过一个生鲜次日达我的项目，生鲜特地是肉类，当用户量上来了，洽购少了补采来不及，洽购多了，当天就坏了，所以，对于咱们技术部来说，最大的挑战在于，为什么咱们能提前一天就晓得 5 吨肉刚好就能卖完，咱们可能实现这样的业务场景撑持，就是信息智慧化带来的后果。
DDD（畛域驱动设计）起源于 2004 年前后，却随着 SOA、微服务开始遍及。
DDD 利用场景
在我看来，业务畛域层是一个互联网公司最外围的局部，它是一个公司业务模式 - 技术化的载体，会有十分多的职能方一起参加进行开发，比方公司的业务架构师、产品经理、其它兄弟部门。
但随着参加人多了，沟通是一个问题，特地是岗位职能齐全不同，鸡同鸭讲、对牛弹琴，而对于简单的业务、关联方更多，沟通老本可想而知。DDD 就是面向这种场景下的解决方案，它是对业务需要的高度形象，基本目标是帮忙咱们了解和剖析业务，在多方沟通、交付中，对立建模了解，以领导进一步的技术实现。
DDD 的劣势
我的项目健壮性：对于技术同学来说，谈到代码健壮性，咱们往往会提到高内聚、低耦合，这对于不少开发同学来说，在业务开发最开始的时候，并不是什么大问题，在我看来，健壮性真正的挑战来源于，是在一直变动的业务需要、和开发工夫之间的抵触下，与日俱增造成的，而 DDD 推崇的是，对业务需要的高度形象，因而，它能够在最基本上缩小咱们业务需要变动的可能性，从而带来业务健壮性上的晋升。
业务灵活性：对于 DDD 设计架构的我的项目，因为外围实现、边界切割十分清晰，在很多业务场景下，胶水层或者 controller 层的实现，相似于积木堆砌，因而能够预感的是，在这种模型下，只有外围服务不产生重大变更，它的业务灵活性将十分强韧。
工程易保护：DDD 只是一种设计思维，它的作用场景次要在于业务架构师、产品经理、技术开发等等多方协同工作，因而，在工程维护性上，绝对于咱们常说的代码可读性等等，它能够影响更多兄弟部门，堪称是降维打击。
DDD 对前端的挑战
前端职能面向交互：对于前端开发同学而言，咱们次要的工作量在于交互层面的实现，很少会直观的去关注，在一个业务场景下，为什么用户能够去抽奖，为什么用户抽中后，能够告诉用户领奖，对于前端开发而言，对于一个业务闭环背地的“为什么”关注比拟少。
设施、场景裂化重大：我以前做过一个需要，也是一个抽奖的性能，然而，要求在微信端、非微信 H5 端、PC 端、还有微博端都做实现，这里就产生了一个问题，如果我的业务逻辑在 C 端实现，同样的代码，我必须实现很多份，一个小小的变动，我可能须要发版屡次，最终，计划逻辑只能是放在 server 端，所以，这是设施、场景裂化带来的局限性。
业务积淀驱动力有余：受限于咱们在业务闭环上的关注度、设施、场景裂化，这就导致咱们很难再抽出额定的精力去关注业务积淀。
掌门教育 DDD 实际
咱们团队在一起沟通 Mapping 我的项目需要的时候，举过一个例子，将来咱们业务利用的开发方式，应该像带烟囱的工厂，工厂厂房是聚合平台，它是一个黑盒，厂房下面一个个独立的烟管，就是咱们一个个独立的利用进口。
比方，政府机构提供了一个查问用户身份证的 API，A、B、C 三个游戏公司的利用，对接实名认证性能，或者用户充值，对接支付宝、微信的领取性能，他们之间的业务界线应该十分清晰。
因而，对于咱们做规定模块来说，其中十分外围的局部，就是如何帮忙咱们的 C 端开发者，做好业务畛域边界划分。
其次，咱们 Mapping 我的项目开发过程中，最开始在做状态模块、决策模块，或者流程模块、数据处理模块的时候，我始终在思考是否要合并做，因为它们之间的关联性十分强，最终咱们抉择离开来实现，起初在做 Mapping 二期需要设计的时候，就十分庆幸之前的抉择，因为咱们发现新的模块对一期局部功能模块依赖也很强，如果一开始咱们设计没有做好拆散，咱们的援用老本就很高，须要做多层不同数据字段值校验，而拆散洁净后，如果援用局部是一个 StateNode 模块，或者是一个 Schema 模块，咱们能够只对类型做校验，而不须要做字段数据值校验，这可能帮忙咱们躲避很多无意义的问题。
总结与思考
1. 业务高内聚、低耦合：将来，咱们技术开发同学，将不可避免的，须要去面对更简单、更多变的业务需要，应答之道，在我看来，除了咱们在做代码实现的时候，须要采纳更正当的设计模式、分层开发之外，咱们更须要可能紧跟公司具体的业务场景，以业务畛域驱动为沟通根底，对齐一条线上的 OKR，能力做到事倍功半。
2. 我前几年看过的一个数据，大略意思是，咱们当初每天产生的数据，可能都比 21 世纪以前的数据量加起来都多，这么海量的数据，背地代表的将是海量的业务场景，可想而知，咱们的业务需要多样性也将是海量的，这也就对咱们如何可能疾速了解、消化、并对业务进行技术实现，带来很大的挑战，但在精细化运作的时代，一个公司不可能像过来那样单打独斗就能有一番作为，肯定是多人、多方协同上来实现业务，从这个方面登程来看，我感觉 DDD 大有可为。
3. 之前跟敌人开玩笑，举过一个例子，我说以前大家玩 Dota，会补刀、会抉择适合机会放技能，就算厉害了，过了两年，如果不会补刀、择机放技能，就是菜鸡了，游戏还是同一个游戏，然而有了积淀、有了积攒，缓缓大家就拉开差距了，DDD 对于咱们技术开发同学来说，其实是一个与公司业务倒退独特成长中，一个很好的桥梁。
