象观敏捷之旅-初探DDD

最近才看到领域驱动设计的概念（孤陋寡闻了的一回），初步看下来，和前几年在做运营商系统的时候常用的概念模型或者叫业务对象模型类似，移动的三户模型，老外的eTOM模型应该都属于这个范畴。简单讲隔行如隔山，要想开发好运营商的系统，必须先积累运营商行业的业务模型，所以世界那么大，做运营商系统的公司就那么几家。正好借着对DDD的好奇，再系统的学习和梳理一遍，看多少记多少。

领域模型的认知

• 领域模型（Domain Model）是一个商业建模范畴的概念，他和软件开发并无一丝一毫的关系，即使一个企业他不开发软件，他也具备他的业务模型，所有的同行业的企业他们的业务模型必定有非常大的共性和内在的规律性，由这个行业内的各个企业的业务模型再向上抽象出来整个行业的业务模型，这个东西即“领域模型”。
• 一个并没有行业经验积累的软件公司，它开发的软件，基本上完全是需求驱动，而不是领域模型驱动。只有具备了领域模型积累的公司才有资格去谈领域模型驱动软件开发。
• 举例来说，我们编一个运营商的CRM系统，如果你只关注了账户的增删改查，这叫做贫血！而实际上你应该关注的是账户的业务特征，而不是数据特征，你应该关注的是账号开立的业务，账户注销的业务，账号过户的业务等等，这才是领域模型。这种领域模型在一个单纯的技术实现层面来说，对于最简单的业务，你可能只是Account类的增删改查，但是对于复杂的业务来说，他就不单但是一个类，一个表的简单操作了，例如开户，你要创建用户信息、处理号码资源、收取费用、触发服务开通以及打印发票和免填写单，那么此时你需要的就是一组协作的类。
• Martin提到领域模型，意在强调我们应该关注软件的业务，关注行业知识的内在规律，并且把这种规律建模为领域模型，批评拿到一个软件，脑子里面光想到数据库增删改查的人。

领域模型的内涵

• 分层架构与职责划分：领域驱动设计很好的遵循了关注点分离的原则，提出了成熟、清晰的分层架构。同时对领域对象进行了明确的策略和职责划分，让领域对象和现实世界中的业务形成良好的映射关系，为领域专家与开发人员搭建了沟通的桥梁。
• 复用：在领域驱动设计中，领域对象是核心，每个领域对象都是一个相对完整的内聚的业务对象描述，所以可以形成直接的复用。同时设计过程是基于领域对象而不是基于数据库的Schema，所以整个设计也是可以复用的。
• 使用场景：适合具备复杂业务逻辑的软件系统，对软件的可维护性和扩展性要求比较高。不适用简单的增删改查业务。

比较重要的两本书

• Domain-driven design【Eric Evans】
• 彩色UML【Peter Coad】（推荐，N年前买过一本，借出去就还回来…郭总~）