正文
![]()
“不要把网络边界当作写更好代码的借口。”
一个简单的事实是，任何技术栈，包括微服务在内，都不能成为写更简洁更易于维护的代码的动力。虽然当条件减少时，你写出来不科学的代码的可能性会降低，但是这就像是通过减少商店里的贵重物品来降低犯罪率一样，没有解决任何问题。
一个流行的方法是围绕一个领域的逻辑服务构建你的代码结构。这反映了微服务的理念：它可以帮助你显式地管理领域所需的依赖关系，并使得关键业务逻辑不会蔓延到多个地方。此外这些服务之间的调用不再过度使用网络，也避免了一些潜在问题的发生。
这种方法的好处在于，基于良好的前期设计和对领域的准确理解，你很容易将它抽取出来，一旦你决定了采用微服务架构，它能帮助你非常准确地围绕微服务构建面向服务架构。一个坚固的SOA方法开始于代码本身，并随着时间地推移，将它扩展到整个技术栈当中。
![]()
“分布式事务从来不简单。”
虽然最开始看起来非常简单，但是大多数领域（尤其是对那些初创公司需要经过多次原型迭代和改造的领域）并不适合将他们规规矩矩地划分成为不同的领域。通常一个特定的子领域需要访问其他子域的数据来正确地完成相应的工作。当需要向它自己以外的领域写入数据时，事情会变得更加的复杂。一旦你打破了自己的业务范围，并且需要其他人参与请求流来存储修改数据时，那你就必须面对分布式事务（有时被称作Sagas）。
在一个请求中涉及到多个远程服务需要通讯时，复杂的问题便随之而来了。例如调用是否可以并行，或者必须串行完成？你是否意识到这些调用中任何一个环节都有潜在地发生错误的可能性（包括应用错误和网络错误）？这对请求本身来说意味着什么？通常每个分布式事务都需要他们自己来处理可能发生的故障，这很可能带来巨大的工作量，不仅仅是错误的解析、错误的处理，更包括如何在出现错误时恢复事务。
![]()
