引言
有一个认可度比较高的对于软件系统架构的定义：职责明确的模块或者组件、关联关系、约束和指导原则。如下图所示：
当我们通过需求分析得到了业务的实例化规则以及领域模型之后，接下来就是进行系统的架构，按照上面对架构的定义，其中比较重要的步骤就是对系统进行拆分与集成。
拆分的好处
将系统拆细之后主要可以简化认知与增加复用。
简化认知：将系统拆细后一次只需要理解少量的概念，在一个特定的范围内工作。在工作中与其他域的同事进行合作的时候很难的地方就是概念的理解，面对一个新的名称或者同一个名称的不同用法（解释）时往往难以短时间理解，因此在系统设计中没有必要不要轻易的新增概念。
增加复用：当把系统拆细之后，每个子系统都有自己特定的问题域，可以屏蔽一些特定的依赖（隔离了变化），因此可以增加复用度。
拆分的粒度
在目前的工作中，根据粒度的不同从大到小可以拆分成应用、模块（jar包）、包、类等几种。
子域与应用
拆分的原则与过程
拆分最重要的原则是：领域体现的业务能力，也就是说拆分出来的子系统有没有可能成为一个独立的业务。这里独立的业务更多针对的是应用级别的，当然也可以暂时把子域放到一个应用中，不过需要具备独立出来的条件。就目前工作中较少遇到可以独立应用的机会。
拆分的过程：根据业务的流程，对每个业务流程进行分析，看该业务流程是否符合独立业务的条件（除了在目前的业务场景下使用，还有没有可能为其他业务使用）。
集成
集成是由双方组成的，依赖方与被依赖方，作为被依赖方，也就是服务提供方，主要有两种方式，一种是产品化方式，不提供业务定制化能力，提供的是标准服务，例如支付宝的支付服务，短信的发送服务等；另外一种是供应商方式，根据客户的需求来定制一些服务接口，在业务部门，一般都是供应商模式。作为依赖方，主要考虑是否新增防腐层，防腐层的好处是依赖倒置，可以随时替换下游，方便测试等，不过增加了模型转换的成本。
jar包与package
在应用内部，一般会按照横向的层级以及纵向的业务来划分。
横向的层级划分按照领域驱动分层一般如下。
jar包一般可以按照上面的模式来划分，不过也可以通过package的方式来组织，只是一种逻辑的代码组织方式，另外有一些公共的功能模块也可以抽在这一层级，例如异常、日志、注解等。
然后是领域模块下面按照各个聚合来划分纵向的业务包package。
类
最后是类的填充与细化，可以是契约导向的编码，由外而内，因为外部的场景是确定，内部的模型可以通过场景来推到出来。
其他
上面基本列出了从领域模型到代码划分的大概过程，省略了很多细节，不过可以作为实践的一个指南，后面会结合一些具体的实例进行分析。
