以下内容为本人相关知识读后总结，细节完全参考风尘浪子《结合领域驱动设计的SOA分布式软件架构》
地址：http://www.cnblogs.com/leslies2/archive/2011/12/12/2272722.html#t1
| SOA | DDD |
|
具体应用程序的功能是由一些松耦合并且 具有统一接口的组件（Service）组建起来 主要针对多核心多平台之间的交互 |
领域驱动设计 将企业内部复杂的业务流程转成服务或软件
|
| 大型系统的总体架构（注重项目分离，隔离开发），最终系统合并 |
单个项目开发管理过程 分为：基础设施层（类似DAL） 领域层（BLL） 应用层（用来协调表现层与领域层） 表现层 实现依赖于模型驱动设计（Model-Driven-Design） Model包含（Entity带标识符实体，ValueObject实体属性，Service） |
细说Model
1.Entity(带标示符)
public partial class Order:IRoot { private Guid _guid; public Order() { _guid=new Guid.NewGuid(); } public Guid GUID {get {return _guid;}} public partial class Person:IRoot { private Guid _guid; public Order() { _guid=new Guid.NewGuid(); } public Guid GUID {get {return _guid;}}
OrderItem作为Order的值对象ValueObject List<OrderItem>
2.Repository原则（分界管理）
OrderRepository只关注Order的CRUD,不包括Person,OrderItem作为Order的ValueObject，CRUD也应放在此Repository中。
例如：
public interface IOrderRepository {Ilist<Order> GetLIstByPerson(int PID); ......CRUD} public interface IPersonRepository {Ilist<Person> GetList(int PID); ......CRUD} 以ADO.NET Entity Framework为例 //获取 _context.Order.Include("OrderItem").where(x=>x.ID==id); //更新 public int UpdateOrder (Order order) { 1.事务 tanscationScope 2.获取Order对象 参数 order.id 3.赋值更改 4.删除原有的OrderItem 5.遍历添加新OrderItem 6.SaveChange(); }
3.领域层服务
复杂的业务逻辑-----》领域服务类
例：在Order表里记录的是每次交易的过程，每次商品的送货费（Freightage）为10元，当商品价格（Price）超过98元可免费送货，当用户 Person积分（Point）超过2000分可获7折优惠（Favorable），1000~2000分可获8折，1000分以下可有9折，最后总体价 格为为（TotalPrice）。
public class AccountManager { private Person _person; private Order _order; public AccountManager(Person person, Order order) { _person =person; _order= order; } public void Account() { GoodsCount(); PricesCount(); FavorableCount(); double price1=(_order.Price - _order.Favorable).value; FreightageAccount(price1); _order.TotalPrice=price1+_order.Freightage.Value); } }
4.应用层（SOA系统中的应用层）
| SOA系统中的应用层 | ||
|
特点：1.协调领域层的工作，只会领域对象解决业务，但本身不参与业务状态 2.承担数据运输中心和信息发放端口的责任（数据的转换和收发） 如：调用领域服务类AccountManager和PaymentManager完成复杂业务逻辑 |
||
|
粗粒度 |
分布式系统：假定外界对系统内部毫不了解，用户只需要舒服数据，等待返回结果， 不关心业务逻辑。 （数据结果封装在数据传输对象DTO） 如：页面需要三个对象的一些属性，Person,Order,OrderItem则值需 将3个类的属性封装成DTO对象（也就是粗粒度元素数据）
|
|
|
传输型 |
SOA系统，应该从性能上出发，优先考虑粗粒度元素的传输型问题。如：原有Person 与Order为一对多关系，但是表现层需求只为11关系，则DTO返回传输， 应以11关系为主 |
|
| 封装性 |
利用Facade模式把一些功能封装在少数的几个服务里 如：表示层Client需要涉及多个类的功能，如Person，Order,OrderItem的Account等 功能。则此时创建OrderService，隔开表示层与多个类的交互，直接交互Facade对象 OrderService 的Account功能。 |
|
Ps:Facade外观模式
外观模式 例：保安有三个设备警铃、监视器、灯，如果要将其全部打开，则要接触三者对象，外观模式则帮助创建Facade对象，保安直接接触facade对象完成打开操作即可。隔开三者对象与保安的耦合关系 三个对象 public class Ring Sensor Light facade对象 public class Facade {Ring=new; Sensor=new;Light=new; void Open(){ Ring.Open(); Sensor.Open();Light.Open(); } } Client对象 public class Client { Facade f=new ; f.Open(); }
5.应用层的协调性（领域层与表现层）
应用层利用Repository完成实体CRUD操作，并调用领域层的服务来管理逻辑
如：OrderService通过调用领域服务AccountManager，PaymentManager等领域服务，完成复杂业务逻辑
public class OrderService { private IOrderRepository orderRepository=DataAccess.CreatOrderRepository(); private void Account(Order order) { IPersonRepository =CreatPersonRepository(); Person p= personRepository.GetPerson(); Account acount........}
数据转换过程
OperationAssembler类作为数据转换器，将多个类对象转成表示层所需要的DTO对象。
7架构图
