书接上回，码意浓在与大师深入探讨了架构设计后，便投身于全新嵌入式系统的开发工作。忙碌的日子里，他的内心却始终萦绕着一个未解的疑惑：新系统要如何通过一套代码，灵活地应对全国各省的差异化需求？大师曾提及的“组件化”概念，这些组件要能够扩展、替换和编排，从而实现高度的可扩展性和可配置性。这些想法一直在他脑海中回响，但他却苦于无法将这一理念落地。于是，他决定再次拜访大师，寻求指点。
码意浓：大师，我又来叨扰了。
大师：哈哈，欢迎啊，小码。你无事不登三宝殿，是不是有什么新进展想和我分享？
继续阅读
码意浓是一位软件开发人员，他最近心情不错，因为他将要负责一个关键的嵌入式系统软件开发。他决定拜访自己多年的老师，听听大师的意见。
大师：码意浓，好久不见，看你气色不错，有什么新鲜事想聊聊吗？
码意浓：嘿，大师，我正好有个新项目想请教您。我们打算开发一个新的嵌入式系统来替换那个已经服役快20年的老古董了。
大师：哦，终于要更新换代了，这可是个大好事。那个老系统确实已经跟不上时代了，维护起来也是头疼得很。
码意浓：是啊，说起来都是泪。不过我也有点担心，新系统的设计可不是件容易的事。
大师：别担心，我们一步一步来。你给我讲讲这个新系统。
继续阅读
这几天大连车务段火了，因为Flash停用，导致车系统不能用，奋战24小时用Ghost和Flash降版本恢复使用。本来恢复就恢复了，可是把这个宣传成敢于攻关、敢于创新、敢于领先，就被全网程序员笑话了。
可是程序员朋友们，先别笑话那些业余选手，想想你手上的遗留系统改造了吗？
继续阅读
最近我给一家传统的大型电子制造业公司做嵌入式系统平台架构咨询。他们的产品硬件部分已经组件化，但是每年都有一部分元器件单元要替换，相应的软件就要修改。最大的痛点就是由于系统耦合严重，一改就容易出问题，工作量还大，团队苦不堪言。
这样的问题不仅出现在嵌入式领域，也出现在传统的软件领域。例如你是否依赖于某个外部系统，想要替换掉它却发现代码已经耦合在一起动不了？又或者某个类库/中间件已经无法满足要求，却又不敢更换？
究竟应该如何处理好外部依赖呢？
继续阅读
说到DDD难，我觉得主要是两点：建模难、代码落地难。前者需要业务熟、功力深，难以快速提升；后者难在缺乏简单易行的可参考的代码结构，一旦有了这样的参考结构，就可以快速大幅降低DDD的实践难度。本文从后者的诸多难点中选择一个最常见的问题进行探讨：如何优雅地实现聚合的持久化？
继续阅读
这是我为Thoughtworks洞见翻译的当提到“事件驱动”时，我们在说什么？，英文原文：What do you mean by “Event-Driven”?
继续阅读