架构师资料教程

Java Is A Dead-End

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

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

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

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

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

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

Object oriented vs. functional prog

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

  前面的帖子很绕，我反思了一下，基本赞同banq关于“业务领域”和“领域模型”的说法。好了，DDD锵锵三人行继续开会。  我在百度百科上查了一下关于“领域”的定义：

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

1.客观主体(例如“企业”)具有业务；2.领域属于某个客观主体的具有一定边界的业务。3.从领域抽象出模型。上面应该是共识，但我感觉仍然有问题没有弄清楚。1.客观主体和领域的关系？2.客观主体和领域的对应关系：一对一或者一对多？3.领域和模型的对应关系：

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

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

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

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