• 这是来自drdobbs的Dino Esposito文章。在领域驱动设计提出后这十年,DDD已经证明对于某些复杂项目是有效的,为实践提供了适当的指导。 大约十年前,Eric Evans提出新的软件开发方法:领域驱
  • 我是一个初学者,以前一直在写程序,是的,说实话,我发现我没有遇到过一家公司是按照面向对象的建模来进行的(前期分析设计),都是采用数据库建模来进行设计的,我看了很多关于'领域驱动设计"的文章,我发现有些话,说了跟没有说是一回事(我没有别的意思)。我看了下的感觉,就是要对你所开发软件的行业进行
  • 最近又重温了领域驱动设计的原著,有了一些新的理解。现在我觉得我能更好地理解jdon007之前说的下面这段话了。 “用户需求”不能等同于“用户”,捕捉“用户心中的模型”也不能等同于“以用户为核心设计领域模型”。 《老子》书中有个观点:有之以为利,无之以为用。 icon
  • 我来用简要的描述一下DDD和DCI的突破性思维。为什么需要DDD / MVC / DCI ,其实是对人类思维可控性的考虑。我们需要着重于DSL思维,要更加靠拢需求和用例。而DCI的提出让OLD DDD 重新考量,而让DDD提供了必要的几个概念,而这些概念也是为DCI框架提供的工具。 icon
  • 当一个人进入人群进行所谓科学随机的检查抽查时,他以为他得到了科学客观的结论,其实他没有考虑到自己的介入导致结果的不正确性,量子力学的薛定谔猫定理也大概是这个意思,这篇文章列举了大量这种检查悖论的现象: 一个常见的例子是班级人员数量的明显矛盾。假设你 icon
  • 前段时间看了下color uml 和 dci 发现 四色原型可以直接通过dci来实现 觉得非常不错。在网上看了几个dci的例子——主要是转账那个,然后自己开始琢磨1个使用技能子系统的实现(我是做游戏的...) 通过trait 实现了 部分类之后 发 icon
  • 我在上文中已经提到,淘宝支付宝在感性的双十一节曾经服务中断,而Twitter可以在全民参与的总统大选中无发生任何意外,将中外技术比较是否有些不公平?但是我看到有人也进行另外一个不公平的比较,将支付宝和铁路售票系统12306进行比较,这里不公平不是指管理运营机制,无疑支付宝是市场经济的代表,我说的是业 icon
  • 目前需求:1.用户可以关注店铺 2.店铺每天都有动态信息推送到系统中 3.用户可以查看最新动态(当然是自己关注店铺的动态列表) 其他的需求不继续详细说明。 icon
  • 业务需求:1. 一个客户可以有多套房子的房贷2.签署贷款合同以后要监控是否按照还贷计划表来执行3.自动还款,当多套房贷时,一次还款可能包括多个房贷的额度,需要自动匹配4.可以提前还款5.可以延长或缩短贷款的时间6.利率可以调整7.滞纳金的问题< icon
  • 看了flyzb 的对领域驱动设计的初步认识博客 icon
  • 在我知道DDD之前,对于如何给类命名,我曾经提到过以下的想法。 如果我们用客户习惯使用的词语来命名类呢?这难道不让我们更容易向客户解释我们为他们实际建造了什么吗? 当然,实际中有可能是完全错误的,但我想说我们与客 icon
  • 这篇文章的目的是:为什么可访问性很重要使网站可访问测试可访问性关于可访问性的错误观念可访问性影响所有用户,而不仅仅是那些有特定障碍的用户。接受这一点意味着实现可访问性就是建立压力 icon
  • 这是来自itproportal的报道,最近一个英国保险公司LV=建立了一个经纪人工作流程的应用,在三个系统上使用三个处理过程实现自动跟踪和报告系统,根据这种复杂性,你猜测这个项目也许需要一个大型的熟练工程师团队数月才能完成,但是事实是:只有两个开发者在一 icon
  • 一段有趣的对话,恐怕很多人亲身经历过,写下来供大家一笑。 甲: 我想添加这个功能,很重要的,必须实现。 乙: 没问题,nothing is impossible。 甲: 太好了,您真是牛人,什么都能做。 乙: 请问给我多少时间。 甲: 呃 icon
  • 通用建站过程 用例1:制定栏目数据模型 参与者:网站管理员 业务规则:细胞数据模型是数据库字段名称、类型、保存方法、处理方法、显示样式等内容的集合。例如:文章标题数据模 icon
  • 我们所知道的用户注册一般是这样的,先注册后然后必须绑定手机的绑定手机,必须绑定邮箱的绑定邮箱。但对于特殊业务,比如只有绑定手机才能使用的业务并不适合。比如Calling Card业务,就是打电话一种业务。因为你不绑定手机就没有办法使用。那么对于这种业务,在手机端的注册流程是否可以改为先发送验证码,然 icon
  • 在互联网经济中,Chris Dixon认为: 在评估互联网公司的战略地位(其利润护城河的可辩护性)时,您需要考虑:1)公司如何产生收入和利润,2)整个循环,而不仅仅是公司产品的层次。 如,考虑进行Goog icon
  • 很多时候,客户对他们想要解决的问题提出的是一个“假的确定性”需求。他们可能没有定义真正的问题需求,而是经常定义解决方案。风险在于如果将其误以为需求我们可能构建错误的系统。软件团队希望能够探索问题的不确定性,以便创建一个出色的解决方案。当产品所有者与客户合作定义问题时,然后再与团队合作 icon