精华内容
下载资源
问答
  • 回顾Bob大叔的简洁架构

    千次阅读 2017-02-28 17:48:57
    Robert Martin 就是我们常说的Bob大叔,是码界的骨灰级人物了,在4年前提出了所谓的简洁架构,值得回顾反思一下,看看是否可以借鉴到微服务中呢?


    Robert Martin 就是我们常说的Bob大叔,是码界的骨灰级人物了,在4年前提出了所谓的简洁架构,值得回顾反思一下,看看是否可以借鉴到微服务中呢?


    大叔在文中介绍了一下几种知名的架构思想:


    • Alistair Cockburn 的Hexagonal Architecture

    • Jeffrey Palermo 的 Onion Architecture

    • Screaming Architecture 在Bob 大叔的博客上

    • DCI 是 James Coplien, 和 Trygve Reenskaug提出的架构模型

    • BCE 是 Ivar Jacobson 在其著作 Object Oriented Software Engineering: A Use-Case Driven Approach 提出的


    尽管这些架构在细节上有各种各样的不同,大叔认为是相似的,都有着相同的目标就是——关注点分离,通过关注点分离把软件分成若干层,系统都是这样的:


    1. 独立的框架。架构不依赖于功能丰富的软件库,把框架作为工具而不是系统的约束。

    2. 可测性. 商务逻辑可以不依赖TUI, 数据库, Web , 或其他外部元素就可以测试。

    3. 独立的UI. 无需改变系统的其他部分就可以轻松地改变,例如 一个 A Web UI 换成控制台UI,而无需改变业务逻辑。

    4. 独立的数据库.业务逻辑不与数据库绑定,可以在各种数据库间切换例如 Oracle 和SQL ,Mongo与 BigTable、 CouchDB等。

    5. 外部代理的独立性. 事实上,业务逻辑需要简化到无需知道外面的世界。


    因此,大叔提出的简洁架构试图将这些架构集成为一种简单的表达形式。



    这一架构工作的最高原则就是依赖原则。这一原则说明源代码依赖指向内部的,内圆不知道外圆的一切, 特别地,外圆中声明的东西不需要被内圆中的代码涉及,包括函数,类,变量以及其他的软件实体。同心圆代表了软件的不同领域。一般地,越深入负责,软件的层次越多。外圆代表机制,内圆代表策略。同样的,外圆中的数据格式也不应被内圆使用,尤其是那些被外圆中的框架所生成的数据格式,并不希望外圆影响到内圆。


    实体 (Entities)


    实体封装了企业级的业务逻辑。一个实体可以是一个带有方法的对象,或者一个数据结构和函数的集合,实体可以被企业内的多个应用使用的。如果没有企业只是写单个应用的话,这些实体就是应用的业务对象。他们在外部变化时改动最少,例如,不希望页面导航的改变影响到实体对象的改变或者安全性。应用的操作性改变不应该影响实体层。


    用例 (Use cases)


    这一层的软件包含了应用相关的特定业务逻辑,封装了所以的系统用例。这些用例编排了实体之间的数据流,目标是将实体指向企业层面的业务规则。同样不希望这一层影响到实体,也不希望这一层被外部元素所影响例如 数据库, UI,  或其他通用框架。然而,希望应用操作的改变影响这一层的用例,如果一个用例的实现细节改变了,这一层的一些代码一定受到影响。


    接口适配器 (Interface Adapters)


    该层的软件是一组适配器的集合,这些适配器将数据转换成用例和实体方便使用的格式,以及一些外部代理方便使用的格式例如数据库或者Web。例如,一个包含MVC架构的图形界面,Presenters, Views, 和 Controllers 都位于该层。models就像数据结构一些从controllers传递到use cases,然后从用例返回到presenters 和 views。


    类似的,来自实体和用例的数据会被转换到驻留框架,例如数据库。这一层没有向内的代码来感知外部的数据库。如果数据库是一个SQL 数据库的话, 那么所有SQL被限制在该层,这一层中特殊的部分处理数据库。这一层中还有其他一些适配器转换外部服务的数据到内部使用的用例和实体。


    框架与驱动(Frameworks and Drivers)


    最外层油框架和工具组成,如数据库,Web框架等。 一般地,不需要写大量的代码就可以和内部的圆进行通信了。这一层细节密布,Web 是细节实现,数据是另一种细节,把他们保持在外可以减少伤害。


    大叔的简洁架构只有四层么?绝对不是的,这些圆不过是示意而言,可以远多于4层的。但依赖原则总是适用的,最外圈总是底层的具体实现。


    右下角的框图展示了是如何跨越边界的,描绘了Controllers 和Presenters 如何与下一层的用例通信。注意一下控制流,开始于controller, 穿过用例在presenter中执行。这也是源代码依赖,向内执行用例。这就是通常使用的DIP,在Java中,可以通过接口和继承关系来实现跨边界的控制流,动态的多态性可以跨越这一架构的所有边界。跨越边界的典型数据是简单的数据结构。可以使用基本结构或者简单的数据传输对象,或者函数的调用参数,重要的是相互隔离。例如,很多数据库框架都在查询时返回一个数据集, 最好不要让它跨边界传递,它违反了依赖原则即内圆知道了外圆的事情。


    回顾


    通过将软件分层,遵守依赖原则,形成内在的可测性,隔离外部的元素并具备可替代性,如此而已。


    简洁架构更像是一种指导性的原则,核心同样是关注点分离和分层感知,没有摆脱企业级应用架构的经典观念。


    如果联想一下复变函数中的保角变换,这 Clean Architecture 就会变成我们熟知的有趣模样了.......




    微信扫一扫
    关注该公众号

    展开全文
  • Bob 大叔讲解编程基础,点赞转发多了就直接翻译成中文,当然真正的程序员是看的懂的,不管是英语还是汉语,程序员都能看的懂代码的。
  • Bob大叔1小时编程基础知识介绍,生动有趣过目不忘点赞多了就翻译 Bob大叔1小时编程基础知识超级生动让人过目不忘,点赞多了就翻译成中文供更多人学习 ...

    Bob大叔1小时编程基础知识介绍,生动有趣过目不忘点赞多了就翻译

    Bob大叔1小时编程基础知识超级生动让人过目不忘,点赞多了就翻译成中文供更多人学习

    展开全文
  • Robert Martin 就是我们常说的Bob大叔,是码界的骨灰级人物了,在4年前提出了所谓的简洁架构,值得回顾反思一下,看看是否可以借鉴到微服务中呢? 大叔在文中介绍了一下几种知名的架构思想: Alistair Cockburn ...

    Robert Martin 就是我们常说的Bob大叔,是码界的骨灰级人物了,在4年前提出了所谓的简洁架构,值得回顾反思一下,看看是否可以借鉴到微服务中呢?

    大叔在文中介绍了一下几种知名的架构思想:

    • Alistair Cockburn 的Hexagonal Architecture

    • Jeffrey Palermo 的 Onion Architecture

    • Screaming Architecture 在Bob 大叔的博客上

    • DCI 是 James Coplien, 和 Trygve Reenskaug提出的架构模型

    • BCE 是 Ivar Jacobson 在其著作 Object Oriented Software Engineering: A Use-Case Driven Approach 提出的

        尽管这些架构模型在细节上有各种各样的不同,但Bob大叔认为是相似的,都有着相同的目标,那就是——关注点分离(分而治之?),通过关注点分离把软件分成若干层,系统都是这样的:

    1. 独立的框架。架构不依赖于功能丰富的软件库,把框架作为工具而不是系统的约束。

    2. 可测性. 商务逻辑可以不依赖TUI, 数据库, Web , 或其他外部元素就可以测试。

    3. 独立的UI. 无需改变系统的其他部分就可以轻松地改变,例如 一个 A Web UI 换成控制台UI,而无需改变业务逻辑。

    4. 独立的数据库.业务逻辑不与数据库绑定,可以在各种数据库间切换例如 Oracle 和SQL ,Mongo与 BigTable、 CouchDB等。

    5. 外部代理的独立性. 事实上,业务逻辑需要简化到无需知道外面的世界。

         因此,大叔提出的简洁架构试图将这些架构集成为一种简单的表达形式。

    这一架构工作的最高原则就是依赖原则。这一原则说明源代码依赖指向内部的,内圆不知道外圆的一切, 特别地,外圆中声明的东西不需要被内圆中的代码涉及,包括函数,类,变量以及其他的软件实体。同心圆代表了软件的不同领域。一般地,越深入负杂,软件的层次越多。外圆代表机制,内圆代表策略。同样的,外圆中的数据格式也不应被内圆使用,尤其是那些被外圆中的框架所生成的数据格式,并不希望外圆影响到内圆。

    实体 (Entities)

    实体封装了企业级的业务逻辑。一个实体可以是一个带有方法的对象,或者一个数据结构和函数的集合,实体可以被企业内的多个应用使用。如果没有企业只是写单个应用的话,这些实体就是应用的业务对象。他们在外部变化时改动最少,例如,不希望页面导航的改变影响到实体对象的改变或者安全性。应用的操作性改变不应该影响实体层。

    用例 (Use cases)

    这一层的软件代码包含了应用相关的特定业务逻辑,封装了所有的系统用例。这些用例编排了实体之间的数据流,目标是将实体指向企业层面的业务规则。同样,我们不希望这一层影响到实体,也不希望这一层被外部元素所影响(例如 数据库, UI,  或其他通用框架)。然而,希望应用操作的改变影响这一层的用例,如果一个用例的实现细节改变了,这一层的一些代码一定受到影响。

    接口适配器 (Interface Adapters)

    该层的软件是一组适配器的集合,这些适配器将数据转换成用例和实体方便使用的格式,以及一些外部代理方便使用的格式。例如数据库或者Web。例如,一个包含MVC架构的图形界面,Presenters, Views, 和 Controllers 都位于该层。models就像数据结构,从controllers传递到use cases,然后从用例返回到presenters 和 views。

    类似的,来自实体和用例的数据会被转换到驻留框架,例如数据库。这一层没有向内的代码来感知外部的数据库。如果数据库是一个SQL 数据库的话, 那么所有SQL被限制在该层,这一层中特殊的部分处理数据库。这一层中还有其他一些适配器转换外部服务的数据到内部使用的用例和实体。

    框架与驱动(Frameworks and Drivers)

    最外层由框架和工具组成,如数据库,Web框架等。 一般地,不需要写大量的代码就可以和内部的圆进行通信了。这一层细节密布,Web 是细节实现,数据是另一种细节,把他们保持在外可以减少伤害。

    Bob大叔的简洁架构只有四层么?绝对不是的,这些圆不过是示意而言,可以远多于4层的。但依赖原则总是适用的,最外圈总是底层的具体实现。

    右下角的框图展示了是如何跨越边界的,描绘了Controllers 和Presenters 如何与下一层的用例通信。注意一下控制流,开始于controller, 穿过用例在presenter中执行。这也是源代码依赖,向内执行用例。这就是通常使用的DIP,在Java中,可以通过接口和继承关系来实现跨边界的控制流,动态的多态性可以跨越这一架构的所有边界。跨越边界的典型数据是简单的数据结构。可以使用基本结构或者简单的数据传输对象,或者函数的调用参数,重要的是相互隔离。例如,很多数据库框架都在查询时返回一个数据集, 最好不要让它跨边界传递,它违反了依赖原则即内圆知道了外圆的事情。

    回顾

    通过将软件分层,遵守依赖原则,形成内在的可测性,隔离外部的元素并具备可替代性,如此而已。

    简洁架构更像是一种指导性的原则,核心同样是关注点分离和分层感知,没有摆脱企业级应用架构的经典观念。

    如果联想一下复变函数中的保角变换,这 Clean Architecture 就会变成我们熟知的有趣模样了.......

    原文链接:https://blog.csdn.net/wireless_com/article/details/58608154

    展开全文
  • 译者注: Bob大叔14年后再次谈论极限编程。极限编程经历了14年的风风雨雨后,Bob大叔将会给它怎么样的定义那? 在我手中拿着的一本白皮薄书,在14年前彻底的改变了软件世界。这本书的标题是解析极限编程,副...

    译者注: Bob大叔14年后再次谈论极限编程。极限编程经历了14年的风风雨雨后,Bob大叔将会给它怎么样的定义那?

    在我手中拿着的一本白皮薄书,在14年前彻底的改变了软件世界。这本书的标题是解析极限编程,副标题是拥抱变化。作者是Kent Beck,出版时间为1999年。

    这本书很薄,不到200页。排版很宽,间隔很远。写作风格即自由散漫又平易近人。章节不多,概念简单。

    但是其影响却像地震一样,甚至至今震动仍未平息下来。

    起始于第53页的章节10,列出了12项实践,引爆了行业内的大辩论。并催生了一场革命,改变了我们编写软件的所有方式。这些实践是:

    • 计划游戏:当今被成为SCRUM。此观点认为软件应该按照任务列表中的优先级循序渐进的开发。

    • 小版本:应当频繁和渐进式地部署软件。

    • 隐喻:该概念最终在Eric Evans编写的《领域驱动设计》一书中明确化。系统结构应当建立在针对问题域的简单的智力模型之上。

    • 简单设计:任何时候都要保证系统尽可能的简单,不用考虑对未来的担心。

    • 测试:程序员和客户一起编写自动化测试来验证产品代码的行为与预期一致。当今我们称之为测试驱动开发(TDD)及验收测试驱动开发(ATDD)。

    • 重构:软件内部结构能够并且应当被持续改进。

    • 结对编程:如果团队成员各自单独工作,那么这称不上一个团队。真正的团队需要经常通过键盘进行合作。这样可以相互充分的分享知识, 正是团队成员的义务。

    • 集体所有权:代码归属于整个团队,而不是某个个体。

    • 每周工作40小时:经常加班的团队是失败的团队。

    • 现场客户:在团队中加入一名真正的客户,用于对需求负责,开发团队能够始终轻易的接触到他。

    • 编码标准:团队应当使用一致的编码风格保证代码整洁,易于沟通。

    争议?

    很奇怪是不是?是不是并不是所有实践都有争议?但是14年前引起了疯狂争议。确实,整本书出版时,人们争议书中的描述不可能应用于实践,争议所有拥护者是如何的必躬屈膝,不听劝解,甚至是一行代码没写过的傻子……

    呃,我不应当让这些过去的感受压倒我。因为,毕竟它们早已消失不再,而我们依然存在。

    看看这12项实践,你没有践行其中哪项?我温柔的读者中的大多数可能长期的践行大多数实践。如果说它们已经被普及肯定稍显夸张,但是更不夸张的说,它们现在已经成为主流。更重要的是,还未践行这些实践的团队至少在尝试它们。这些实践已经可以被完美的落地实施,而不再是一个被唾骂的异端。

    崛起

    过去的14年已经变得陌生。极限编程论战催生出来的敏捷运动,飞速成功,随后被项目经理接受,但是将程序员排斥在外。我们已经看到了确定性的、疯狂的成功,以及相应的(可预见的)无力的认证。我们看到了只采用了计划游戏(例如SCRUM)而忽略其他11个实践的策略失败了。这种策略被Martin Fowler称为无力的Scrum。我们已经经历了咨询师和作者分离的持续的推动,以及看板、精益及每一个新的项目管理方法的竞争。我们已经看到了软件工艺运动的发展,以及敏捷基因被慢慢的退化和稀释。

    在所有的炒作和翻腾中,这12项实践依然留存,只是其中一些名字有稍微改变。一周工作40小时变成了可持续增长率。测试变成了TDD。隐喻变成了DDD。小版本变成了持续集成和持续部署。但是尽管名称改变,但是这些实践依然和14年前描述的差不多。

    我们也看到极限编程这个名称几乎完全不用了。极少数人现在还使用这个词。一些人仍然使用XP这个缩写,但名称的大部分都已经消失。如果听到一个团队描述他们正在做的是极限编程,甚至正在践行所描述的这12项实践,我会觉得非常罕见。名称变了,但是实践未变。这些实践是持久的。 在翻腾,炒作,争议的咆哮和胡言乱语中,在人类争夺一个又一个位置的风雨中,在人类的贪婪,激情和骄傲的杂乱中,在所有的政治中,这些实践依然留存。

    稳定的价值观

    我相信这些实践这么持久是因为他们基于稳定的价值观这个坚实的基础。Kent Beck在他的书中第7章第29页描述了这样的价值观:

    • 沟通

    • 简单

    • 反馈

    • 勇气

    我可以尝试论证为什么这些价值观是正确的,但是我他们自身已经论证了这些。软件工匠能够拒绝这些价值观中的任何一个吗?软件工匠能够不努力争取在工作中保证这些价值观的展现吗?这些价值观正是软件工艺的价值观。

    我可以尝试辩论书中这12项实践拥抱和体现了这些价值观,但是这些实践的持久性足够证明,尽管围绕这些实践的名词和运动已经消散。

    成功

    极限编程已经成功了!它成功的超越了其支持者的最疯狂的梦想。它的成功是因为从诞生时的争议中幸存下来,在不可避免的倡导者的流失中幸存下来。它成功了是因为它活的比自己的名字更久!

    极限编程的成功正像结构化编程的成功。甚至没人再会考虑结构化编程,因为他们一直在使用结构化编程。我们正在尝试达到没人再会考虑极限编程的目标。

    这就是成功!一个想法从这场运动诞生一直存活到成为我们日常生活的一部分,这就是成功!

    回顾

    所以现在,2013年的最后几个星期,我花了些时间回顾1999年。那个时间Kent Beck写了一个突破性的书。这本书改变了一切。回顾并谨记:极限编程。简单的说,请承认它是:

    优秀的软件实践的核心

    原文出处: http://blog.8thlight.com/uncle-bob/2013/12/10/Thankyou-Kent.html, 作者Uncle Bob Martin。

    转载于:https://www.cnblogs.com/huang0925/p/3472289.html

    展开全文
  • 所谓软件架构,就是你希望在项目一开始就能做对,但是却不一定能够做得对的决策的集合。 ——Ralph Johnson ... Martin(Bob大叔)在架构领域的登峰之作,更是因为书中重现了,半个世纪以来几乎所有的软件架
  • 如今,他是设计模式和敏捷开发先驱、敏捷联盟首任主席、C++ Report前主编、Object Mentor公司的总裁,他被后辈程序员尊称为“Bob大叔”。 在我认识的人中,Bob大叔是最聪明的之一,他对编程有着无尽的热情。如果有...
  • Robert C.... Report 前主编,被后辈程序员尊称为“Bob大叔”。20世纪70年代初成为职业程序员,后创办Object Mentor公司并任总裁。Martin还是一名多产的作家,至今已发表数百篇文章、论文和博客,除本
  • Robert Martin 就是我们常说的Bob大叔,是码界的骨灰级人物了,在4年前提出了所谓的简洁架构,值得回顾反思一下,看看是否可以借鉴到微服务中呢? 大叔在文中介绍了一下几种知名的架构思想: Alistair ...
  • 此文是本人今天在重读BOB大叔的《敏捷软件开发》第六章后的一个小小读后感。 先给大家说说第6章里BOB都做了什么: 首先,BOB先和同伴打个招呼,让这次合作有个愉快的开头。 然后是一个极短的讨论,他们确定需要写一...
  • Bob大叔观OO原则

    2015-09-24 08:53:00
    Bob大叔建议:在日常工作中,只有当出现“臭味”时我们才会去使用它,如果只是因为它是一个原则就无条件的遵循它那是错误的,过分的遵循这些原则会导致不必要的复杂性和设计臭味。 个人认为,一切均应切合实际,要...
  • Coplien首先让Uncle Bob定义了一下TDD,Uncle Bob说明了他的三个法则:(敏捷的同学一定不陌生)  一个测试驱动的程序员,其不会在写出一个测试失败的Unit Test前,去写一句可用在生产线上的代码。(没有测试之前...
  • Bob大叔的书太经典了,拜读过大名鼎鼎的《企业应用架构模式》和《重构》,感觉相当经典,今天找到《敏捷软件开发 原则、模式与实践》,抽空好好品味一下。...
  • 什么是优雅的代码? 我喜欢优雅和高效的代码。代码逻辑应当直截了当,叫缺陷难以隐藏;尽量减少依赖关系,使之便于维护;依据某种分层战略完善错误处理代码;性能调至最优,省得引诱别人做没规矩的优化,搞出一堆...
  • 1、设计模式。必须能描述GOF书中全部24种模式,同时还要有POSA书中的多数模式的实战经验。 2、设计原则。必须了解SOLID原则,而且要深刻理解组件设计原则。 ...必须理解XP、Scrum、精益、看板、瀑布、结构化分析及...
  • 当有人查看底层代码实现时,我们希望他们为其整洁、一致及所感知到的对细节的关注而震惊。我们希望他们高高扬起眉毛,一路看下去。我们希望他们感受到那些为之劳作的专业人士们。但若他们看到的只是一堆像是由酒醉的...
  • ”,这是2008年2月18日的视频,视频的主角两个人争论TDD好还是不好,一个是敏捷社区的教主级的人物——Robert Martin(大家称之为“Bob大叔”),另一个是C++,OO,多范式编程的大师 Jim Coplien (大家都叫他Cope)...
  • Summary ...Debate sprang up at JAOO '07 around Bob Martin's assertion that "nowadays it is irresponsible for a developer to ship a line of code he has not executed in a unit test." I...
  • 程序员常刷题克诺 Kerno 试图成为: 在 Python 中构建应用程序的框架 这近似于 Robert C. Martin ...通过授权一个服务层(这里称为Action ...框架)移到系统的边缘,同时仍然提供使开发和自动化测试更容易的方法。...
  • 周末刷了一下视频 – 编程的未来,1942年出生的Bob大叔,1个小时20分钟全程手舞足蹈的讲解了编程的历史和未来。感触挺深,所以特地来分享一下。1970年开始从事编程工作(18岁),敏捷的鼻祖,Robert C. Martin 著著名...
  • 如果你知道 Bob 大叔,如果你对他的整洁之道有所耳闻,你一定能想象这场直播具有的非凡意义。从 2001 年敏捷宣言的诞生,到 2009 年《代码整洁之道》的面世,再到之后的《代码整洁之道:程序员的职业素养》,今年,...
  • Joel vs Bob, 敏捷其实很无聊

    千次阅读 2009-02-25 21:10:00
    这是两位大牛关于TDD的争论,详细内容看这里。首先介绍下两位。Joel,大名鼎鼎的blog站点Joel on software的作者,部分文章居然有中文翻译版。...Bob大叔,Robert Martin,何许人也?敏捷运动的发起人之
  • Martin,软件开发大师,设计模式和敏捷开发先驱,敏捷联盟首任主席,C++ Report前主编,被后辈程序员尊称为“Bob大叔”。20世纪7 0年代初成为职业程序员,后创办Object Mentor公司并任总裁。Martin还是一名多产的...
  • In order to defend and preserve the honor of the profession of computer programmers, I Promise that, to the best of my ability and judgement:为了捍卫和维护计算机程序员的职业荣誉,我承诺,尽我所能和...
  • Bob大叔的整洁架构英文原版, 非常清晰,是进行软件架构设计不可多得的最佳入门书籍。
  • 《代码整洁之道》读书笔记

    万次阅读 多人点赞 2015-04-10 15:52:23
    《代码整洁之道》是Bob大叔神一样的作品,这本书从引言到附录都无比精彩,书中的插图也非常好,代码是用Java语言书写的,程序员尤其是Java程序员赶紧去阅读吧!
  • 应人民邮电出版社图灵公司的邀请,我有幸参与了Bob大叔所著CleanCoder的翻译。与前作CleanCode不同,这本书着重讲述的是开发人员的“职业素养”,也即职业开发人员应当如何做事。在阅读中,我时常会忍俊不禁,也会...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,758
精华内容 703
关键字:

bob大叔