• 对象和数据的主要差别就是对象有行为，行为可以看成责任职责(responsibilities以下简称职责)的一种，理解职责是实现好的OO设计的关键。“Understanding responsibilities is key to good object-oriented design”—Martin
  • 领域模型的行为设计是面向对象领域建模设计的重要部分。 在没有设计的朴素的情况下，领域模型一般是一个数据对象(DTO等)，其中只有setter/getter方法，是一种纯粹的数据结构，然后将很多数据结构的算法操作设计在Service等专门接口类中。这样，数据
  • DDD领域驱动设计给我们指出统一建模统一语言的方向，从辨识角度提出区分实体和值对象的方法，如果说DDD只是给出了领域建模的方向，也就是WHAT部分，那么， icon
  • 由 Robert Martin提出的S.O.L.I.D 原则，用来更好编写面向对象程序，更灵活应对变化。 S - Single Responsibility Principle 单一职责，简称SRP这个我前面几篇文 icon
  • 最近我和oojdon讨论给帖子加上浏览阅读次数这个功能，起初我们并没有从职责角度来考虑阅读次数这个功能，就简单地在Service中获得Thread方法时，添加一些代码，用来统计次数。 因为我们这时重点是如何用Domain Events来实现阅读次数持久化问 icon
  • 一篇译文：我的大脑不能再处理面向对象了，作者认为他的大脑更适合处理面向过程，也就是函数式编程。 我个人观点：面向对象号称以适 icon
  • 今天在jdon看到一片关于领域模型的文章，心里总结了一下 下面是个人观点！ 贫血模型是对OO的非常经典的诠释！数据交给s/g，业务全部交给业务对象来完成。耦合度很低，逻辑清晰，重构空间大！而且在业务逻辑上 icon
  • 我们现在有一个模型Member，我想输出Member的性别，比如先生、女士。是否可以在模型中有这么一个方法 @Transientpublic String getSexLang() { return sex = 1 ? "先生" icon
  • 微服务是SOA的发展演进，但是来自IBM一篇博客文章好像将两者完全置于平等的角度进行比较，本文翻译中加入了本人的批判观点。 如果你在IT部门工作，可能已经听过SOA与微服务的争论。毕竟，现在每个人都在谈论微服务和敏捷应用程序。 icon
  • 从“贫血”和“充血”说起 这两个词对我来说也是很新鲜的，看看我在Jdon的注册日期也就是从那时候开始才有所耳闻的。这两天看到有人在讨论于是整理了一下思维。 看到网络上很多的讨论中对于充血和贫血的看法往往是以绝对的 icon
  • Arch-orchestrator是一个用于管理大型Node.js应用的类似SOA Orchestrator 开源的流程指挥器。 < icon
  •   DDD中强调“领域对象是拥有行为的”。这句话我觉得说法是正确的，但是其做法难道就是“在领域对象里写方法”这么简单吗？   我们常说“类应该具有生命的”，但我不认为“把方法写到类里就会让类具有生命了”，因为"把简单地把方法写到类里， icon
  • -->>失血模型 　　MF（Martin Fowler）曾经提出有名的贫血模型或失血模型，让我们好生迷惑和彷徨，他认为实体模型对象中只有弱行为setter和getter方法，没有真正行为，好像缺少血液的人，不和谐了，不少高手又被忽悠了，大谈贫血模型。 icon
  • 充血模型有什么实际的好处么？ 难道就为了好听 完美（数据和行为统一）？ 过于复杂的需求还是用贫血 ,一般需求用充血 ,这样做正确吗？ 项目中用的更多的哪个模型呢。 比较 icon
  • 最近正在自学建模。打算以设计一个论坛做为目标。初步确定了论坛中有用户、管理员、论坛、帖子等对象。我想问一下，像添加帖子这种功能是否应该属于哪个对象？是应该放在用户对象还是帖子对象中？还有，像注册用户、消息的发送管理这些功能是应该独立出来成为一个服务还是放到用户对象中去？思考来思考去，感觉一脑 icon