DAS 1.1测试时内部服务器在处理接收的单据时崩溃的情况(有产生crash文件).导致程序不再进行后续处理. 在测试环境已出现两种错误配置导致崩溃的情况。 为此已增加启动时校验规则配置功能处理这类问题. 情形1：<command>语句的别名字段在目标表中不存在 产生异常的代码位置及说明如下:                         for (int col=0;col<fld_num;c

2004年，当Eric Evans的那本《领域驱动设计——软件核心复杂性应对之道》（后文简称《领域驱动设计》）出版时，我还在念高中，接触到领域驱动设计（DDD）已经是8年后的事情了。那时，我正打算在软件开发之路上更进一步，经同事介绍，我开始接触DDD。   我想，多数有经验的程序开发者都应该听说过DDD，并且尝试过将其应用在自己的项目中。不知你是否遇到过这样的场景：你创建了一个资源库（Reposi

传送门：【HDU】3076 ssworld VS DDD 题目分析：简单的概率DP。。不过要搞清楚转移边界。。。我就因为边界问题一直wa。。 PS：题目数据给的血量是反的！数据错了 代码如下： #include <cmath> #include <cstdio> #include <cstring> #include <algorithm> using namespace std ; #defi

ssworld VS DDD Time Limit: 4000/2000 MS (Java/Others)    Memory Limit: 65536/32768 K (Java/Others) Total Submission(s): 1487    Accepted Submission(s): 304 Problem Description   One day, sssworld and

kao，WA了那么多次这题目数据是错的，两个人的血量弄错了，输入的 A的血量其实是B的，输入B的其实是A的，由于有平局现象的干扰，所以一开始先把平局包括进去 的 A赢的概率B赢的概率都算出来，然后减去以后就是平局的概率，再在已经除去平局的情况里 算一下A赢的概率，B赢得概率计算出来，这样就可以计算了， 假设方程dp[i][j]代表 A赢了j次B赢了i次的概率，然后状态转移就比较简单了 ： dp[i

最近的开发工作涉及到两个模块“任务”和“日周报”。关系是日周报消费任务，因为用户在写日周报的时候，需要按一定的规则筛选当前用户的任务，作为日周报的一部分提交。整个项目采用类似于Orchard那种平台加插件的架构，“任务”和“日周报”是两个独立的插件。 “任务”已经由一位同事事先写好，周报中筛选任务的规则简单描述如下： 截止日期在周一之前，且未完成的任务（超期或待审核）； 截止日期在周一至周日之间的

在实际的项目中，我们可能随时面对各种不同的需求，它的各个方面的要素决定了我们所采用的开发模式。 比如，它的复杂度如何？所有的需求是否足够清晰？开发人员对相关的业务是否足够了解？项目的工期是否合理？种种问题，不一而足。这也决定了我们可能面对不同的需求可能需要采用不同的开发模式。下面大概说几种。   1. TDD TDD指的是Test Drive Development，很明显的意思是测试驱动开发，也

本文既不推销UML，也不推广DDD，更不涉及各种论战。-- 作者     某天又一次打开关于DDD(领域驱动设计)的PDF文档时，自己有了个疑问：什么是领域(Domain)？译文中是这样描述领域：银行业务被银行的内部人员和专家所熟知。他们知道所有的细节、所有的困难、所有可能 出现的问题、所有的业务规则。这些就是我们永远的起始点：领域。如果这就是领域，它似乎不是"起始点"，而是“全部”--全部的业务

最近学习intern,在网站上看到一些不太理解的词语:TDD,BDD, so百度了一下: 在实际的项目中，我们可能随时面对各种不同的需求，它的各个方面的要素决定了我们所采用的开发模式。 比如，它的复杂度如何？所有的需求是否足够清晰？开发人员对相关的业务是否足够了解？项目的工期是否合理？种种问题，不一而足。这也决定了我们可能面对不同的需求可能需要采用不同的开发模式。下面大概说几种。   1. TDD

简单的概率DP。因为输入顺序反了，。错了N次。，， 代码如下： #include <iostream> #include <string.h> #include <math.h> #include <queue> #include <algorithm> #include <stdlib.h> #include <map> #include <set> #include <stdio.h> usi

DDD: 领域驱动模型 OOD: 面向对象的设计。 测试驱动开发TDD TDD主要通过单元测试进行。在编写功能代码前，先编写单元测试代码。

关注“思特沃克ThoughtWorks”微信公众号，输入“洞见”或者“Insights”可以查看最新发布的洞见文章。 案例： 一家咨询服务公司的Timesheet系统 需求 1) 公司的所有员工能够登陆到系统填写每周工作的时间、内容。 2）公司有两部分员工，一类是办公室人员，一类是咨询人员； 3）咨询人员是为某个项目工作，在每个项目里的角色不尽相同；每个项目的Timesheet要求也不同，根据角色

ssworld VS DDD Time Limit: 4000/2000 MS (Java/Others)    Memory Limit: 65536/32768 K (Java/Others) Total Submission(s): 1607    Accepted Submission(s): 330 Problem Description One day, sssworld and DD

To Repository Or NOT 好文要分享下，老外写的，地址 http://www.codeproject.com/Articles/875165/To-Repository-Or-NOT 顺便说下另一个项目，基于DDD设计的，ComBoost ，ComBoost is Wodsoft's entity repository technology for applications. Do

其实，在之前的Nature框架中已经描述了不少，不过，这里，还是想完整的阐述一下其中的概念。 不过，肯定比较简略，如果真的要深入理解，还是要读《领域驱动设计》《实现领域驱动设计》这两本书。 好啦，接下来进入正题。 首先是关于聚合的内容。我们认为，相关联的一些事物，构成了一种叫做聚合的概念。比如，说到书，他就会有封皮，书名，每页书，作者等等等等。他们是聚合在一起的，说到书，就代表了那一堆东西。而书这

介绍         领域驱动设计涵盖的知识点比较多，其中代码的架构、设计、编写基本上只占到其中的很小一部分，其它的大部分讲解的是需求的获取方式、项目的管理方式等知识。本篇就是针对这一小部分的知识点位来展开的。所以本篇的学习前提是只需要了解DDD的架构分层即可。 应用场景        DDD领域驱动设计中一旦领域驱动层模型建立完毕，就会产生出数据库持久化的接口即仓储的接口供其它层来做具体实现，所

实体 实体是业务系统中分析得出的业务对象，诸如用户、产品之类的，它们需持久于数据层，有自己的属性。 但实体并不是数据展现层所需的数据载体，它只是一种业务载体。它定义的关于本实体的业务方法，并将这些业务方法所对本实体的改变持久化到数据层。 实体不提供直接修改其内部业务属性的方法，也就是说，不再有setter方法。改变内部业务属性只能是有能表达业务、并能通用语言表达的方法来处理。 实体不提供直接读取其

领域驱动设计（DDD）是一种软件设计的思考方式。它以领域为核心，分析领域中的问题，通过建立一个领域模型来有效的解决领域中的核心的复杂问题。Eric Ivans为领域驱动设计提出了大量的最佳实践和经验技巧。只有对领域的不断深入认识，才能得到一个解决领域核心问题的领域模型。如果一个应用的复杂性不是在技术方面的，而是在领域本身，即领域内的业务很复杂，那这种应用，使用领域驱动设计的价值就越大。 领域驱动开

上周六很高兴参加了博客园组织的DDD分享交流会，我有幸给参会者分享了我对DDD的一些理论理解、案例分析，以及最后简要介绍了一下ENode框架。这次分享重点分享了几个DDD的小型建模案例，并在会上与大家进行了讨论。为了推广DDD，吸引更多的人去了解DDD，我把PPT转换为pdf在公众号上也分享一下。另外，还有一个PPT的录像视频，有兴趣的朋友可以加ENode QQ群：185916873 pdf下载地

ABP是“ASP.NET Boilerplate Project (ASP.NET样板项目)”的简称。 ASP.NET Boilerplate是一个用最佳实践和流行技术开发现代WEB应用程序的新起点，它旨在成为一个通用的WEB应用程序框架和项目模板。 ASP.NET Boilerplate 基于DDD的经典分层架构思想，实现了众多DDD的概念（但没有实现所有DDD的概念）。 ABP的官方网站：ht