架构运维

领域驱动设计之领域模型2004年Eric Evans 发表Domain-Driven Design –Tackling Complexity in the Heart of Software (领域驱动设计),简称Evans DDD。领域驱动设计分为两个阶段: 以一种领域专家、设计人员、开发人员都能理解的通用语言作为相互交流的工具,在交流的过程中发现领域概念,然后将这些概念设计成一个领域模型;由领域模型驱动软件设计,用代码来实现该领域模型; 由此可见,领域驱动设计的核心是建立正确的领域模型。 为什么建立一个领域模型是重要的领域驱动设计告诉我们,在通过软件实现一个业务系统时,建立一个领域模型是非常重要和必要的,因为领域模型具有以下特点: 领域模型是对具有某个边界的领域的一个抽象,反映了领域内用户业务需求的本质;领域模型是有边界的,只反应了我们在领域内所关注的部分; 领域模型只反映业务...

消息场景:用户 A 发送一个消息给用户 B,用户 B 回复一个消息给用户 A。。。 现有设计:消息设计为实体并为聚合根,发件人、收件人设计为值对象。 三个问题: 实体最重要的特性是什么? Message 实体是怎么得来的? 发件人、收件人为什么不是实体? 1. 实体最重要的特性是什么?《领域驱动设计》5.2 实体: 摘录一段:许多对象不是由它们的属性来定义,而是通过一系列的连续性(continuity)和标识(identity)来从根本上定义的。 归纳: 标识(identity) 连续性(continuity) 标识在实体中的另一种体现就是唯一和不可变,其概念在很多资料中有说明,这也是实体最重要的特性。 我有一个双胞胎哥哥,我们俩出生的时候,长得一模一样,以至于我们的爸妈都分不清,不得已他们在我们脖子上系个项链来标记:谁是老大?谁是老二?其实这个“标记”就可以看作是实体的...

REST围绕着资源这个概念而构建的,然后用URI来表示。然后一个HTTP动词和资源URI组合起来对指定资源进行HTTP调用来执行操作。大多数REST框架提供了指定资源名称的生成器,框架围绕着它来生成脚手架。不幸的是,许多这些生成器使用CRUD模型(Create,Read, Update, Delete)作为默认的起始点。资源被定义为一系列的属性,使用类似JSON Schema或某个具体语言的数据对象来定义,然后生成方法存根,然后来创建,读取,更新和删除该资源。 尽管这可以让开发人员觉得理解和开始工作变得简单了许多,是一个很好的起点,但是使用CRUD作为API的起点,我有一个很大的疑问。就是CRUD中的U是我最不喜欢的。让我们来谈谈U.通用更新方法允许客户端更新资源的任何字段,然后使用新版本覆盖现有版本。但是,如果允许客户端执行这样的操作,您的服务API在其使用的任何底层数据存储之上,...

我以前写过一篇关于领域事件的文章——实现领域事件,随着在项目中深入的使用DDD架构,我对领域事件有了新的认识。尤其是采用领域事件来解耦代码这种方式对项目的发展具有深远的影响。 我在实现领域事件中主要谈到了如何在技术层面去实现发布事件与订阅事件,比较了几种不同的方式以及它们背后的原理。但随着我在自己负责的项目中严格地实施DDD架构时,我发现如何去发布订阅领域事件的意义远没有决定去做这件事情本身重要。换句话说,与其纠结与是使用基于Spring的事件架构还是Guava提供的EventBus,是使用同步发布还是异步发布,还不如想想去做这件事情对你的项目会产生怎样的影响。 为什么要使用事件?我认为这是所有人应该考虑的首要问题。对我来说,使用事件的意义有两个方面,一是在于流程上的解耦,二是在于代码层面的解耦。在代码层面的解耦是显而易见的,我就不再赘述了。那么流程上的解耦是什么意思了?我们先看一下...

当你的系统或者业务变得日益复杂时,DDD的模式是一种非常值得尝试的架构模式。DDD让你更加关注于你的业务领域,思考你的业务模型,帮组你理清繁杂的业务关系。我推荐所有还没有了解过或者接触过DDD的后端工程师都去学习一下该架构模式。本文主要关注DDD中的领域事件,以及一种可能的实践方式。 我们知道领域模型的变化会产生领域事件。例如,用户在完成注册后,系统会发出一封带有确认信息的邮件到用户的邮箱;用户关注的好友发送动态后他会收到相应的通知等等。在业务比较简单或者不用考虑性能的情况下,我们可以直接把对领域事件的处理嵌入到领域服务中。考虑这样一个场景:用户回复了某条评论,那么被回复的那个用户(也就是那条评论的所有者)需要收到一个PUSH消息。这个场景比较简单,我们可能直接写出类似下面的代码: void reply(long fromUserId,long toUserId,String ...

关于领域驱动设计这篇文章参考了Eric Evans《领域驱动设计》一书以及Jimmy Nilsson《以C# .NET为例运用领域驱动设计和模式》,二者详细描述了领域驱动设计的核心概念、技术和模式。在某些情况下,直接使用这些书的措辞是有意义的,并且我认为Eric Evans和Jimmy Nilsson也允许我们这么做。 尽管将方法本身呈现出来是很有用的,但是仅仅对方法进行描述,DDD的许多微妙之处就会消失。这些方法应该是你的工具,而不是你束缚你的规则。它们是为设计而生的语言,在团队内沟通创意和模型十分有益。更为重要的是,记住实践DDD的目的是为了做出更加务实的决定。不要试图将一个方法强加于一个模型。另外,如果你“打破”了一个方法,确保你已经理解了这么做的理由,并将其与其他人沟通。 通常认为,DDD在面向对象范式下表现良好,但远不止这些。DDD解决了如何去理解问题空间这一挑战,甚至是更...

本系列内容是来自Mashape.com的Marco在nginx.conf上的一次演讲。 上一集我们介绍了为什么我们需要API网关:微服务与API 网关(上): 为什么需要API网关? 本系列第一部分(上集)主要介绍了单体和微服务之间的差别,以及为什么我们需要一个API网关等等。 本系列的第二部分(也就是本集)主要关注Mashape.com的API网关,Kong,这个框架。我们来看看怎么使用这个框架。 ok,开始吧。 目录 23:52 API网关和Kong能为你做些什么(API Gateways and Kong Can Help) API 网关可以通过实现一些中间件来解决一些问题,这些中间件的功能你就不用再到每个service中实现了。你也是知道的,不同的团队使用不同的方式来实现了不同的微服务。 如果你不去做一些中心化和抽象化的事情,你将会死于不同的认证方式以及不同的速率限制实...

本文是来自于Macro在一次大会上的一个分享。 本系列共有两个部分,主要关注我们如何以及为什么要在我们的微服务应用中部署API 网关。第二部分主要关注我们如何把Mashape的开源网关组件Kong运用到我们自己的微服务架构当中。* 目录 0:00 微服务与网关(Microservices & API Gateways) 大家好,我叫Macro,今天我们谈论有关微服务和网关的话题。我是Mashape的CTO,也同时是开源网关Kong的开发者之一。Kong是一个API网关,今天我们就来窥探一下它究竟是怎么工作的以及它如何运用到你的微服务架构中去。 0:23 主题(Topics) 为了明白我们为什么需要API网关,我将从单体架构vs微服务架构谈起。这两个有什么不同点呢?然后我会介绍API网关模式以及它是如何适应“面向微服务”的架构的。然后我们会讨论Kong以及NGINX。 ...

原文: http://static.olivergierke.de/lectures/ddd-and-spring/ 介绍这篇文章是的介绍一下领域驱动设计的基础构件、概念和Java的web应用(主要是基于Spring框架)之间的关系和区别。这篇文章的第二部分讲了怎么把实体、聚合根、仓储映射到使用Spring框架的Java应用中。 领域驱动设计Eric Evans的《领域驱动设计》无疑是软件设计领域最重要的几本书之一。这本书主要集中在软件开发中如何处理领域和软件的映射关系— 开始强调领域通用语言(domain ubiquitous language),通过语言来提取模型,最终映射到一个可工作的软件上。我们已经对软件设计模式比较熟悉了,他是用于描述和提炼Class和Class关系的技术语言。而DDD是一种用于程序员和业务沟通的更通用的语言,使用DDD可以最终将代码映射到模型上。 基础...

我承认我是标题党, 为什么要写这篇充满争议的文章?目前架构师这个职位特别火热,程序员的目标都是成为一个令人尊敬的架构师。但是我们真的理解架构师应该做些什么?很多人把架构师和框架师等同起来,认为研究框架多的才是架构师下面说的情况请勿对号入座。 盲目的追新:技术人员的喜好往往是什么技术流行就追什么技术。现在的技术发展快,前后端不断涌现各种框架,我们恨不得把这些框架都用在自己的项目里才行,要不然怎么好意思和别人打招呼啊。我亲身经历,有个技术人员一定要把原来单元测试框架的xml初始数据改为json,他的原话是”json看的更舒服”,但是改完后,我们的单元测试反而难落地了,原因是原来的单元测试框架有个工具是可以将表中的数据自动生成xml的,而改成json后,我们必须手写json数据了。 他的喜好不包括给大家更好用的工具。 按技术站队,以结果反推:很多人把手段当成了目的,成为了框架的信徒。用了...

接上篇,我们采用了领域驱动的开发方式,使用了充血模型,享受了他的好处,但是也不得不面对他带来的弊端。这个弊端在分布式的微服务架构下面又被放大。 事务一致性事务一致性的问题在Monolithic下面不是大问题,在微服务下面却是很致命,我们回顾一下所谓的ACID原则 Atomicity - 原子性,改变数据状态要么是一起完成,要么一起失败 Consistency - 一致性,数据的状态是完整一致的 Isolation - 隔离线,即使有并发事务,互相之间也不影响 Durability - 持久性, 一旦事务提交,不可撤销 在单体服务和关系型数据库的时候,我们很容易通过数据库的特性去完成ACID。但是一旦你按照DDD拆分聚合根-微服务架构,他们的数据库就已经分离开了,你就要独立面对分布式事务,要在自己的代码里面满足ACID。对于分布式事务,大家一般会想到以前的JTA标准,2PC两段式提...

上篇我们聊了微服务的DDD之间的关系,很多人还是觉得很虚幻,DDD那么复杂的理论,聚合根、值对象、事件溯源,到底我们该怎么入手呢?实际上DDD和面向对象设计、设计模式等等理论有千丝万缕的联系,如果不熟悉OOA、OOD,DDD也是使用不好的。不过学习这些OO理论的时候,大家往往感觉到无用武之地,因为大部分的Java程序员开发生涯是从学习J2EE经典的分层理论开始的(Action、Service、Dao),在这种分层理论中,我们基本没有啥机会使用那些所谓的“行为型”的设计模式,这里的核心原因,就是J2EE经典分层的开发方式是“贫血模型”。 Martin Fowler在他的《企业应用架构模式》这本书中提出了两种开发方式“事务脚本”和“领域模型”,这两种开发分别对应了“贫血模型”和“充血模型”。 事务脚本开发模式 事务脚本的核心是过程,可以认为大部分的业务处理都是一条条的SQL,事务脚本把单...

微服务架构和SOA区别微服务现在辣么火,业界流行的对比的却都是所谓的Monolithic单体应用,而大量的系统在十几年前都是已经是分布式系统了,那么微服务作为新的理念和原来的分布式系统,或者说SOA(面向服务架构)是什么区别呢? 我们先看相同点: 需要Registry,实现动态的服务注册发现机制; 需要考虑分布式下面的事务一致性,CAP原则下,两段式提交不能保证性能,事务补偿机制需要考虑; 同步调用还是异步消息传递,如何保证消息可靠性?SOA由ESB来集成所有的消息; 都需要统一的Gateway来汇聚、编排接口,实现统一认证机制,对外提供APP使用的RESTful接口; 同样的要关注如何再分布式下定位系统问题,如何做日志跟踪,就像我们电信领域做了十几年的信令跟踪的功能; 那么差别在哪? 是持续集成、持续部署?对于CI、CD(持续集成、持续部署),这本身和敏捷、DevOps是交织...

简介如今,软件通常会作为一种服务来交付,它们被称为网络应用程序,或软件即服务(SaaS)。12-Factor 为构建如下的 SaaS 应用提供了方法论: 使用标准化流程自动配置,从而使新的开发者花费最少的学习成本加入这个项目。 和操作系统之间尽可能的划清界限,在各个系统中提供最大的可移植性。 适合部署在现代的云计算平台,从而在服务器和系统管理方面节省资源。 将开发环境和生产环境的差异降至最低,并使用持续交付实施敏捷开发。 可以在工具、架构和开发流程不发生明显变化的前提下实现扩展。 这套理论适用于任意语言和后端服务(数据库、消息队列、缓存等)开发的应用程序。 背景本文的贡献者者参与过数以百计的应用程序的开发和部署,并通过 Heroku 平台间接见证了数十万应用程序的开发,运作以及扩展的过程。 本文综合了我们关于 SaaS 应用几乎所有的经验和智慧,是开发此类应用的理想实践标准,并特...

原文是 Martin Flower 于 2014 年 3 月 25 日写的《Microservices》。 微服务“微服务架构(Microservice Architecture)”一词在过去几年里广泛的传播,它用于描述一种设计应用程序的特别方式,作为一套独立可部署的服务。目前,这种架构方式还没有准确的定义,但是在围绕业务能力的组织、自动部署(automated deployment)、端智能(intelligence in the endpoints)、语言和数据的分散控制,却有着某种共同的特征。 “微服务(Microservices)”——只不过在满大街充斥的软件架构中的一新名词而已。尽管我们非常鄙视这样的东西,但是这玩意所描述的软件风格,越来越引起我们的注意。在过去几年里,我们发现越来越多的项目开始使用这种风格,以至于我们身边的同事在构建企业级应用时,把它理所当然的认为这是...