架构的细节

物理分层

　　包，或者组建，项目，都可以是物理分层。物理分层主要为了使灵活部署成为可能。

　　层次之间是否可以直接调用，如果不能直接调用，其产生的先后顺序，以及版本问题，成为考虑问题的一个方面。

　　如果使用后期引用，依赖注入，全部选择还是部分选择，考虑一些效率的影响和开发的难度。

逻辑分层

　　业务分层属于逻辑分层的范围。

　　如果业务层次要清晰，可以更少考虑效率问题，为每个清晰的业务语义层构架一个类，这样能够更好地减小颗粒度，更清晰设计对象

代码细节

　　1. 基本问题，对象层次的建立。一个问题域不能被多次建立，或者分布在多个对象中。

　　2. 基本问题，方法和返回值。一个层内或者整个项目的参数和返回值的确定。

　　返回值是被其他方法调用后的结果，有些人定义成整形符号，有些人定义成字符串描述，有些人则返回一个结构。如果这些返回值不统一，那么调用者会为每个方法的返回费一番脑筋去判断它是否正确执行，所以一定要统一返回值类型。

　　要么是一个整形值结果码，然后通过其他方式获得描述，如从一个列表中获得结果码的含义。

　　要么是一个结构，包含结果码和描述。

　　最好不要是一个字符串描述，对多语言和自动识别都有问题。建议是一个结构。

　　所有的代码都像设计COM一样，考虑到更多的协调代码，自动代码和写代码的人的因素，这样才能让使用者，生产者和消费者都不至于在这个问题上耽误太多时间，或者后续耽误太多时间去重构和修改。因为重构和修改会导致很多单元测试的逻辑发生改变，会造成大面积的错误。

     （未完）