领域模型

一、什么是业务领域建模 领域建模： 从领域模型开始,我们就开始了面向对象的分析和设计过程,可以说,领域模型是完成从需求分析到面向对象设计的一座桥梁。 顾名思义,就是显示最重要的业务概念和它们之间关系，是真实世界各个事物的表示（现实世界的可视化抽象字典）而不是软件中各构件的表示。领域模型是描述业务领域（业务实体）的静态结构。 理论派观点： Domain Model是一个商业建模范畴概念，即使一个企业不开发软件，也具备其业务模型； 所有同行企业，其业务模型必定有非常大的共性和内在的规律性。 由行业内的各个企业的业务模型再向上抽象出整个行业的业务模型，这个模型称之为“领域模型”。 领域模型是一种特殊的业务模型，它分析范围是整个行业，抽象出行业里共性和内在规律性的业务，比业务模型更加抽象，它不属于软件开发范畴的概念，与软件开发无关。 实战派观点： 领域模型是一个分析模型，帮助系统分析人员、用户认识现实业务的工具，描述的是业务中涉及到的实体及其相互之间的关系，它是需求分析的产物，与问题域相关。 是需求分析人员与用户交流的有力工具，是彼此交流的语言。 领域模型是一种分析模型，在软件开发过程分析阶段用于分析如何满足系统功能性需求，属于软件开发范畴，在UML中主要使用类图来描述领域模型。 业务模型是业务建模的输出物，业务建模研究的对象是公司或者组织，业务建模属于软件开发过程中的初始阶段。

业务逻辑架构模式(事务脚本，表模块，活动记录，领域模型) 　　其实各种架构模式并不是凭空出现的，是你写代码到达一定功底的时候自然出现的结果。走的弯路多了，就会主动去思考该如何将代码组织的更好，更符合业务需求与架构标准。 　　Fowler的《企业应用架构模式》 (Patterns of Enterprise Application Architecture)就是这样一本书，里面详细叙述了企业级开发中常用的架构模式。对于业务逻辑层，常见的有四种： 事务脚本，表模块，活动记录，领域模型。见图： 　　注： 　　1.我在这里画了两层：UI与BL，其实如果更极端一些，事务脚本的CRUD，表模式的XXXManage与活动记录的XXXHandler与UI层是可以合并的。 　　2.表模式的XXXManage与活动记录的XXXHandler是同意词，两种不同的表达方式而以。 　　先来看事务脚本，这是一种最面向过程的组织方式，上层UI需要什么操作，下层就对应的写出处理方式。一个方式从UI直接操作到DB，好处是上手快，方便书写，坏处嘛，复用性不够，针对复杂逻辑适应性极差 　　再来看表模式与活动记录。这其实是两种换汤不换药的方式。比事务脚本进步的方面在于将数据库的表对象单独独立了出来，一个类对应一张数据库表。独立的方式有所区别：表模式是一个DataTable对应一张表， 然后附上其CRUD

1、继承的定义 继承是指：可以使用现有类的所有功能，并在无需重新编写原来的类的情况下对这些功能进行扩展。 （1）通过继承创建的新类称为“子类”或“派生类”。 （2）被继承的类称为“基类”、“父类”或“超类”。 继承的过程，就是从一般到特殊的过程。要实现继承，可以通过“继承”（Inheritance）和“组合”（Composition）来实现。 在某些 OOP 语言中，一个子类可以继承多个基类。但是一般情况下，一个子类只能有一个基类，要实现多重继承，可以通过多级继承来实现。 2、继承的分类 继承概念的实现方式主要有2类：实现继承、接口继承。 （1） 实现继承是指使用基类的属性和方法而无需额外编码的能力； （2）接口继承是指仅使用属性和方法的名称、但是子类必须提供实现的能力(子类重构父类方法)； 在考虑使用继承时，有一点需要注意，那就是两个类之间的关系应该是“属于”关系。 抽象类仅定义将由子类创建的一般属性和方法。 OO开发范式大致为：划分对象→抽象类→将类组织成为层次化结构(继承和合成) →用类与实例进行设计和实现几个阶段。 3、示例代码 #!/usr/bin/env python # -*- coding:utf-8 -*- # Author:ZhengzhengLiu #类的继承 classPeople: def__init__(self,name,age): self.name

轻松学DDD之一：模型驱动设计 　　我是2012年开始接触到DDD（领域驱动设计）的， 后续陆陆续续研读过几遍Eric的大作《领域驱动设计：软件核心复杂性应对之道》，也使用DDD重构过一个项目。总的感受是DDD的一些概念比较晦涩难懂，很难掌握，因此想写个系列短文，希望能用通俗易懂的语言帮助大家更轻松更深入地理解DDD。文章很多都是我个人体会和理解，难免有错误，希望大家能及时指正，共同提高。 　　本文是系列短文第一篇，介绍ＤＤＤ的起始概念 模型驱动设计 。 1. 软件开发方法回顾 　　软件开发可以看做是一个把用户需求转换为可正确运行的程序的过程，其中最关键部分是把用户需求转换成代码。我们要学习的DDD实际上就是一种软件开发方法，它相比之前的软件开发方法，能更好地应对软件的核心复杂度。为了能更好的理解它，我们先回顾下之前的软件开发方法及其存在问题。 　　在上世纪６０年代，由于需求简单，软件开发以作坊式开发为主。但是随着硬件的飞速发展，软件复杂度也迅速激增，终于在７０年引发了软件危机。为了应对危机，业界借鉴成熟生产制造管理方法，发展出以“过程为中心”的瀑布式开发方法。 1.1 瀑布式开发 　　瀑布式开发把整个软件开发过程划分为需求分析、方案设计、编码、测试等阶段，希望以这种类似工业流水线的作业分工方式来控制软件开发的风险和成本。 需求分析 ：通过需求分析我们需要明确用户想要的功能

1、什么是Domain Modeling 　　业务对象模型（也叫领域模型 domain model）是描述业务用例实现的对象模型。它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。业务对象模型从业务角色内部的观点定义了业务 用例 。该模型为产生预期效果确定了业务人员以及他们处理和使用的对象（“业务类和对象”）之间应该具有的静态和动态关系。它注重业务中承担的角色及其当前职责。这些模型类的对象组合在一起可以执行所有的业务用例。 业务角色显示了一个人承担的一系列职责。业务实体表示使用或产生的可交付工件、资源和事件。业务 用例 实现显示了协作的业务角色和业务实体如何执行某个工作流程。使用以下几种图来记录业务用例实现： 图显示参与的业务角色和业务实体。活动图，其中泳道显示业务角色的职责，而对象流显示如何在 工作流程 中使用业务实体。 序列图描述业务角色和业务主角之间交互的详细情况，并显示如何在业务用例执行过程中访问业务实体。 业务对象模型将结构的概念和行为的概念结合了起来。 它是一个纽带工件，用于对业务关系进行清晰的表述，表述方式与软件开发人员的思考方式类似，同时仍保留一些纯粹的业务内容。将我们所知道的有关业务的信息按照对象、属性和职责进行了合并。 它探索业务领域知识的本质，所采用的方式使我们能够从对业务问题的思考转变到对软件应用程序的思考上来。 它是一种确定需求的方法

♦ 1) Collect application domain information – focus on the functional requirements – also consider other requirements and documents ♦ 2) Brainstorming – listing important application domain concepts – listing their properties/attributes – listing their relationships to each other ♦ 3) Classifying the domain concepts into: – classes – attributes / attribute values – relationships • association, inheritance, aggregation ♦ 4) Document result using UML class diagram 　领域模型(domain model)是对领域内的概念类或现实世界中对象的可视化表示。领域模型也成为概念模型、领域对象模型和分析对象模型。领域模型是一种概念模型，也叫问题域模型。它表述的是某个领域的现实概念。上世纪80年代开始

Domin Modeling for A StyleTransfer Project 本文阐述基于深度学习框架的风格迁移系统项目的业务领域建模，为系统抽象业务模型，对后续的开发工作进行指导。 一、W hat is Domain Modeling 　 　领域模型（又称概念模型、领域对象模型、分析对象模型）是对领域内的概念类或现实世界中对象的可视化表示分析方法：专注于分析问题领域本身、发掘重要的业务领域概念、建立业务领域概念之间的关系。 　　领域模型是描述业务用例实现的对象模型是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象， 从业务角色内部的观点定义了业务用例，为产生预期结果确定了业务人员以及他们处理和使用的对象之间应该具有的静态和动态关系并且注重业务中承担的角色及其当前职责。 　　领域模型设计的步骤为： 　　　　1. 从业务描述中提取名词； 　　　　2. 从提取出来的名词中总结业务实体，区分名词中的属性、角色、实体、实例，形成问题域中操作实体的集合； 　　　　3. 从业务实体集合中抽象业务模型，建立问题域的概念（例如在前面的例子中，我们把容易变质的水果称之为“短期保持水果”，当然也可以是其它说法，只要能跟用户达成共识即可）； 　　　　4. 用UML提供的方法和图例进行领域模型设计、确定模型之间的关系； 二、Requirment of Project