虽然微服务架构风格有其独特优势，但前提是合理架构、划分业务单元。完全无脑的进行微服务化、拆分成庞大的子系统有时并不是一个好的选择，特别是针对初期项目，基于模块化单体应用架构可能是更好的选择。通过系统的不断迭代，随着上下文变化逐渐演进，是一个建议的方式。

软件架构设计的终极目标不在于设计本身，而在于架构设计意图的传达。图形化有助于在团队间进行高效的信息同步，但不同的图形化方式在语义一致性和效率间存在平衡。C4模型通过不同的抽象层级来表达系统的静态结构，并提供了最小及的抽象建模元素，为设计人员提供了一种低认知负载、易于学习和使用的高效的建模方式。在实际项目落地过程中，结合C4模型以及UML、线框图等组合方式对架构设计进行可视化表达，一定程度上能够提升

状态机时一种非常有效的抽象的系统行为的分析建模工具，在工程实践中具有较高价值。通过对实体状态建模，有利于业务与技术对领域有一致性理解，并能够有效指导后续的工程实现。值得注意的是，技术人员要对业务状态机和系统状态机有清晰认识，不要混为一谈。由于二者出发视角的不同，技术视角的系统状态机更加偏重于实现，业务状态机更加面向客户。

原文来自本人的微信公众号文章  系统工程实验室  引言基于模型的系统工程（简称MBSE，英文全称Model based System Engineering ）的实践至少需要三个维度的支撑：建模语言、建模方法论和建模工具。建模语言为模型的表述提供了统一的支撑，建模方法论为建模的行为提供了更为一致的准则，建模工具为建模的实现提供了更为自动化的支撑。今天要讨论的主题 “IBM Rati

应用架构模式的选择是系统架构设计的重要维度之一，结构不仅仅是简单的包结构和命名，其传达的是一种顶层抽象，背后包含了大量的实践和知识。制定符合团队情况的工程参考架构，并在团队成员间达成共识非常重要。领域驱动设计并没有统一的、通用的架构，试图定义标准架构是不切实际的。本文描述的工程架构只是一个参考，实践过程中应该基于团队特定情况而有所差异，但原则上都应该遵循业务域与技术域分离的核心理念。