架构师资料教程

    对于上一个帖子，大家有一些讨论。有人说“领域驱动设计”非常好，也有人说“领域驱动设计”有问题。其实大家都有道理，我针对大家的讨论进一步谈一下自己的认识。     先谈谈现实业务中的问题域模型

感觉banq活着自己的java世界里，他的世界很大很深，却又什么都有没有！中国缺的不是大师，缺的是奇人，能够打破格局的人，你学的再好，在深，再精通也是拾人牙慧，替别人把老本发扬光大。你可以看看唯物主义，体会什么叫实事求是，学学什么叫创新，希望你和你的团队能做出像android，linux这样

    第一次看到banq关于JF的PPT时，我突然发现原来可以这样建模，领域模型是这样丰富，让领域对象充满了色彩。过去看到的OO都是“简单实体建模”：即从需求中挖出几个实体对象，然后填充属性，至于其它的东西只要会查询就行了。这种建模方式随处可见，实在

Leaving .NET .net社区者之间是没有协作的，这个社区是病态

  我是一个学Java的新手，但已经用.Net开发好几年了。当我发现对于一个系统从小型到中型，再想往上做的时候，希望能够做一个真正面向企业集成规模的软件时，突然发现微软的技术已经无法很好地支撑我想要的东西了。因为把业务真正拆分成不同可独立部署的业务组件时，在.net中

    一边看着Evans的书，一边学习jivejdon源码，同时印证着我的经验和想法后有这样一种感觉：DDD就像一颗闪光的明珠，但从目前来讲还不够完美。     这不禁让我想到一个问题：随着各种新的建模技

    首先声明，《领域驱动设计》对我来说只是一种建模技术，我讨论的前提是在面对企业多业务集成（如ERP、MES、HR、多项目、PDM、MRO）模式下的如何解决业务建模的问题。我提出的观点也许并不适合小项目甚至中型的单项目，因为技术架构和项目复杂度是相适应的。

    从我自身从事企业软件开发历程看，更注重一个“悟”字。由于个人比较喜欢看武侠和玄幻之类的小说，至今每天闲暇之余都是除了看资料就是看小说。从练武的角度看，大家总是在讨论“四色原型”、“类和职责分配、逻辑到底放在服务里还是领域对象里”之类所谓“剑招”的

Object oriented vs. functional prog

    真有意思，讨论DDD了这么久，我们竟然连第一个D——“领域”的含义都没有达成一致。的确，Eric也没有明确地告诉我们。下面我谈谈自己的想法。     首先我们要明白“业务”和“领域”的关系。它

    DDD的方向无疑是正确的，但是看了Eric的DDD以及banq的jivejdon源码后不禁又有了一些疑问。     "贫血模型"无疑是不对的，领域建模中的领域对象应该是有行为的。在jivejdo

Raible Designs | RE: Moving from Spring to Java EE 6: The Ag

先声明一下，此文章只是本人转载的。本一直在jdon上潜水，近日在OSChina正好看到这篇文章，文中观点与Jdon上的大力弘扬的OO思想有点出入，大家可以看下老外的文章是否也靠谱。 任何一位在两个领域里——本地应用程序和Web应用程序——都做过长期开发的人

从事.NET(C#)开发,处在一个以DB为核心的开发中,而周围人热衷于JS,LAMBDA,SQL,LINQ...技巧,某某技术.总觉得大家是在忙着 用什么砖头好, 怎么个砌好这块墙 , 怎么让房子冬暖夏凉, 公司或许会引进一些好用的砌砖工具, 好的砌砖方案, 但是怎么造, 终究是一个平房.现

rationese是我正在开发的编程语言，弄一小段示例代码，展示如何在过程式代码中，使用逻辑编程的搜索方式，看看这种表达方式是否需要，有哪些用处。 示例1：var a[10];a[*]=0 *是通

现在已经有两个这样的论断似已成为共识： 1 简短的不重复的代码就一定强过啰嗦的代码。2 声明式代码一定强于命令式代码。 很可惜，这两个论断，在我看来，在不少的场合都不成立，反对的方式也很明确：