软件构造从用户需求开始
需求即用户对软件功能的描述，用户通过需求告诉程序员他需要收集什么数据，这些数据该怎么处理，最后他希望看到什么结果。需求中描述的场景和内容是软件处理的核心领域，程序员需要通过代码把它表现出来。
即使用户是和你一样的程序员，需求也不可能完善到直接指导编码的地步，而且软件的构建是一个“邪恶（Wicked）”的过程，也就是说某些问题在设计阶段并不显山露水，只有在构建过程中它们才会逐渐暴露出来。这就要求程序员深入问题的领域，了解领域的相关知识，对领域做出合理的抽象，并在软件构建过程中不断完善它，直到完全实现用户需求，具备现代软件的八个主要特征。
二。何谓领域和领域模型
领域即业务领域，是用户进行业务活动的主要内容。一些领域是和现实世界中的实体对应的：如雇员管理系统中的雇员，图书管理系统中的图书，零售系统中的商品，而有些领域
和现实世界中的虚拟实体相对应：如金融系统中的借贷关系，商务系统中的合同关系等。软件的主要任务是数据的收集，整理，表现，存储和传输，而数据的基本单位就是领域模型。
领域模型是现实世界中的实体在代码中的体现和合理抽象，它能表现出实体的基本信息。如果可以说软件环境是现实业务活动在计算机世界的模拟的话，那领域模型就是现实实体在计算机世界的模拟。
三。软件构建的核心是领域模型的建立
领域模型是软件需要处理的数据的基本单元，只有建立起了领域模型，你才能知道软件需要收集，整理，表现，存储和传输的对象是什么。建立领域模型是软件构建的核心环节，如果它没有被合理抽象出来的话，
软件能提供的服务，数据的持久化和数据在软件中的表现都是空中楼阁，因此我们可以说，从现实世界中的实体中抽象出合理的领域模型是软件构建中提纲挈领的一个环节，这一步是软件各个层次
的基石，也是软件构建的起点。不建立领域模型并非一定不能造就出能运转正常的软件，所谓的表维护程序就是典型例子，它们由某些懒惰，愚蠢和无能的程序员造就，他们从来不去认真思考用户究竟想知道什
么，程序究竟在处理什么，而是翻译堆砌代码，仅仅让它能跑出一个正确的结果而已，这样的程序员永远成为不了优秀的程序员，他们生产出的代码也是一堆有危害性的几乎无法维护的垃圾，这堆垃圾将给公司和个人带来潜在的危害，相对而言，对个人的危害性更大，有时甚至可以断送一个程序员的职业生涯。
四。如何建立起领域模型
途径一：分析业务中的业务流和业务规则，从中归纳出功能的基本单位，这个基本单位就是领域模型之一或领域模型的一部分。
途径二：从原型界面中观察显示的数据，它们是领域模型的外在体现。
途径三：从持久化介质中推导领域模型，如从数据库的表结构和ER图中推导领域模型。
途径四：向领域专家问询业务流程中的核心单元是什么，甚至自己进入问题领域去学习探究。
途径五：将不熟悉的领域和相似的自己熟悉的领域做对照，类比出领域模型。
途径六：从已有的知识系统中学习，参考功能相似的软件代码，向优秀代码学习。
五。如何完善领域模型
领域模型是经常发生相互联系的，上一步只是建立了孤立的，仅能表现单个领域对象信息的模型，要使它们丰富完善起来，需要做以下工作：
1)
从程序的功能角度入手，考虑需要几个领域对象才能完成这个功能，再由此考虑领域对象之间的联系。这方面的典型例子是需要雇员类和资源类的协助，借贷关系才能完整的表现出来。
2)
从领域对象本身入手，考虑领域对象之间是否有级联，回溯，包含等常见关系。如个人信息包含地址信息，公司类和雇员类的级联关系，雇员类查找自己所属公司的回溯关系等。
3)
从反持久化入手，考虑把一个领域对象从存储介质中提取出来需要那些领域对象的帮助，这些领域对象是通过那种方式联系在一起的，这方面的典型例子是表之间的主键和外键，领域对象同样也要具有相对应的成员变量。
六。领域对象设计完成之后
一旦领域对象设计完成，程序的设计工作就可以说完成了一大半，其余工作都是围绕领域对象来进行，这些工作有：
1)
从考虑怎么为领域对象服务入手，为领域对象设计服务类，服务类的常用方法有添加，删除，更新，查询领域对象四种以及从ID取得一个领域对象，判断持有某个ID
的领域对象是否存在等。具体的操作实际上由服务类的持久层类成员完成，服务类实际上起到的是一个领域对象上下传输通道的作用。一般来说Service
层的六大函数是add，delete