假设面试:作为一名架构师，面对一个复杂的业务系统，如何一步步设计和实现？以公司现有业务为例
业务需求搜集
flexport作为一个货运系统，首先我们要明白我们的客户是谁，我们的客户主要是shipper和consignee，shipper主要是工厂，consignee主要是工厂或者商家。
主要业务流程: shipper将货物交付给flexport，flexport联系carrier(轮船公司)，将货物运送到consignee指定地点。
我们需要跟所有相关人员以及行业资深专家沟通，了解客户需求
在领域驱动设计中，这一步就是消化知识： Crunching the knowledge
use case风暴以及提炼核心领域对象
通过与领域专家和客户的沟通，我们可以写出一些主要的用户场景。use case其实就是产品文档的主要部分，提取并深入理解use case是设计产品的成功的关键。
1， 发货人（shipper） 提交订单（shipment），明确自己要运送的货物，时间等关键信息
2，flexport 运营人员（operator）确认订单，并向船运公司（carrier）预定仓位和时间
3，运送货物，收货人（consignee）签收
4，flexport开具发票（invoice），发货人付款，订单完成
这只是简单列举了最典型的简化过后的场景。即便这样，我们也能从中提取出核心对象
shipper, shipment, operator, carrier, consignee, invoice， 然后，我们需要逐步细化每一个use case，确定每一个核心对象的属性，方法以及与其他对象的关联。
在领域驱动设计中，这一步就是形成统一语言（ubiquitous language）并且设计对象模型（entity， value object， service）
迭代实现以及反馈
首先产品经理和架构师会提炼最核心的需求，设计出一版简单的系统并实现。交付用户使用以后，一边搜集用户的反馈，一边设计更高级的功能。通常这就是敏捷项目管理流程。
拆分子服务
当我们的服务不断迭代，事情会变得越来越复杂，比如仅仅是跟carrier打交道的部分，我们首先会跟carrier提交一个订单（carrierOrder），然后在运货的过程中还会提交各种文档（document）， 比如billOfLading, CCAM，当这部分足够复杂的时候，就有理由将这部分逻辑独立出来，做成一个子系统。当子系统独立以后，就是涉及到data migration，与现有系统的交互等等
关注实现
架构师并不是高高在上的，他除了需要设计领域模型以及划分子系统，还需要关注底层的实现，小到每一个接口，类，方法，变量的命名和使用，都需要架构师关注，否则很可能设计的领域模型会流于形式，并没有被真正实现，也无法发现设计的领域模型的不合理之处