ddd

最近准备用SpringClound搭建一个微服务框架，因为对服务划分的细节比较纠结，在搜索资料的时候无意中留意到了“领域驱动设计”这个词，初步看了几篇博文，发觉跟自己认识的开发模式有很大的差别。 Martin Fowler在他的《企业应用架构模式》这本书中提出了两种开发方式“事务脚本”和“领域模型”，这两种开发分别对应了“贫血模型”和“充血模型”，我们习惯使用的MVC模式便是贫血模式。 在网上找了一篇详细介绍的博文，决心认真研读一番，读完补上读后感。 博文地址：http://www.cnblogs.com/netfocus/archive/2011/10/10/2204949.html 参考博文： https://blog.csdn.net/alex_xfboy/article/details/77334398 https://blog.csdn.net/alex_xfboy/article/details/77335982 https://blog.csdn.net/alex_xfboy/article/details/53609160 来源： https://www.cnblogs.com/wochenjun/p/9753843.html

上篇总结了下JSON的序列化和反序列化，博园中大牛给了很多牛叉的评论，学习了不少。 不过在上篇中忘了把json序列化和反序列化的另外一种方式写上去了，这里做个简单的补充： Json篇： http://www.cnblogs.com/zhanghaomars/p/3557644.html Json序列化和反序列化扩展方法实现类： using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Web.Script.Serialization; namespace HelpClass.TypeHelp { public static class JsonHelpExpand { public static string JsonSerializer<T>(this T t) where T : class { JavaScriptSerializer jsonSerialize = new JavaScriptSerializer(); return jsonSerialize.Serialize(t); } public static T JsonDeserialize<T>(this string jsonString) {

路由层 1.Django中路由作用 URL配置(URLconf)就像Django 所支撑网站的目录。它的本质是 URL与要为该URL调用的视图函数之间的映射表 ；你就是以这种方式告诉Django，对于客户端发来的某个URL调用哪一段逻辑代码对应执行 2.简单配置 from django.conf.urls import url ​ urlpatterns = [ url(正则表达式, views视图函数，参数，别名), ] ​ -第一个参数是正则表达式(如果要精准匹配:'^publish/$') -第二个参数是视图函数(不要加括号) -url(r'^admin/', admin.site.urls) ​注意: 1.若要从URL 中捕获一个值，只需要在它周围放置一对圆括号。 2.不需要添加一个前导的反斜杠，因为每个URL 都有。例如，应该是^articles 而不是 ^/articles。 3.每个正则表达式前面的'r' 是可选的但是建议加上。它告诉Python 这个字符串是“原始的” —— 字符串中任 何 字符都不应该转义 4.urlpatterns中的元素按照书写顺序从上往下逐一匹配正则表达式，一旦匹配成功则不再继续 3.无名分组与有名分组 无名分组 -按位置传参 -分组之后,会把分组出来的数据,当位置参数,传到视图函数,所以,视图函数需要定义形参 -url(r'^publish

本文算是《领域驱动设计》这本书的读书笔记，加上自己的一些读后感。网上有很多这本书的读书笔记，但是都是别人的，不如自己总结的理解深刻。建议大家在读这本书时结合《实现领域驱动设计》一起看，同时，一定要去实际建模和编码，理论联系实际才能得其精髓。 本文是【DDD】系列文章的第一篇，可参考： 使用领域驱动设计思想实现业务系统 定义 DDD是Domain driven design（领域驱动设计）的简称，是一种软件设计和开发的方法论，特别适用于复杂业务领域软件设计和开发。可参考wiki： Domain-driven_design 核心 将所有业务逻辑内聚到业务领域（domain）层，将设计和开发的关注点聚焦到业务领域； 建立通用的‘业务领域语言（Ubiquitous Language）’，Ubiquitous Language是工程师和业务领域专家（可以是产品经理、运营、业务相关人员）的桥梁； 战略上，通‘上下文（Bounded Context）’解耦各个业务系统/组件，通过‘防腐层（Anticorruption layer）’确保自有业务领域不受外界污染，通过‘开放主机服务（Open Host Service）’向外界公开服务； 战术上，将业务对象建模为entity和value object，entity有唯一业务标识且在其生命周期中状态可变，value object与之相反

1，父级div定义 height <style type="text/css"> .div1{background:#000080;border:1px solid red;/*解决代码*/height:200px;} .div2{background:#800080;border:1px solid red;height:100px;margin-top:10px} .left{float:left;width:20%;height:200px;background:#DDD} .right{float:right;width:30%;height:80px;background:#DDD} </style> <div class="div1"> <div class="left">Left</div> <div class="right">Right</div> </div> <div class="div2"> div2 </div> 原理：父级div手动定义height，就解决了父级div无法自动获取到高度的问题。 优点：简单，代码少，容易掌握 缺点：只适合高度固定的布局，要给出精确的高度，如果高度和父级div不一样时，会产生问题 建议：不推荐使用，只建议高度固定的布局时使用 评分：★★☆☆☆ 2，结尾处加空div标签 clear:both <style type=

本系列所有文章 如何一步一步用DDD设计一个电商网站（一）—— 先理解核心概念 如何一步一步用DDD设计一个电商网站（二）—— 项目架构 如何一步一步用DDD设计一个电商网站（三）—— 初涉核心域 如何一步一步用DDD设计一个电商网站（四）—— 把商品卖给用户 如何一步一步用DDD设计一个电商网站（五）—— 停下脚步，重新出发 如何一步一步用DDD设计一个电商网站（六）—— 给购物车加点料，集成售价上下文 如何一步一步用DDD设计一个电商网站（七）—— 实现售价上下文 如何一步一步用DDD设计一个电商网站（八）—— 会员价的集成 如何一步一步用DDD设计一个电商网站（九）—— 小心陷入值对象持久化的坑 如何一步一步用DDD设计一个电商网站（十）—— 一个完整的购物车 如何一步一步用DDD设计一个电商网站（十一）—— 最后的准备 如何一步一步用DDD设计一个电商网站（十二）—— 提交并生成订单 如何一步一步用DDD设计一个电商网站（十三）—— 领域事件扩展 阅读目录 前言 名词解释 实施DDD的关键 如何构建一个领域的上下文映射图 构建我们的上下文映射图 结语 一、前言 DDD（领域驱动设计）的一些介绍网上资料很多，这里就不继续描述了。自己使用领域驱动设计摸滚打爬也有2年多的时间，出于对知识的总结和分享，也是对自我理解的一个公开检验

前言 设计是把双刃剑，没有最好的，也没有更好的，而是条条大路到杭州。同时不设计和过度设计都是有问题的，恰到好处的设计才是我们追求的极致。 DDD（Domain-Driven Design，领域驱动设计）只是一个流派，谈不上压倒性优势，更不是完美无缺。 我更想跟大家分享的是我们是否关注设计本身，不管什么流派的设计，有设计就是好的。 从我看到的代码上来讲，阿里集团内部大部分代码都不属于 DDD 类型，有设计的也不多，更多的像“面条代码”，从端上一条线杀到数据库完成一个操作，仅有的一些设计集中在数据库上。我们依靠强大的测试保证了软件的外部质量（向苦逼的测试们致敬），而内部质量在紧张的项目周期中屡屡得不到重视，陷入日复一日的技术负债中。 一直想写点什么唤起大家的设计意识，但不知道写点什么合适。去年转到盒马，有了更多的机会写代码，可以从无到有去构建一个系统。盒马跟集团大多数业务不同，盒马的业务更面向 B 端，从供应到配送链条，整体性很强，关系复杂，不整理清楚，谁也搞不明白发生什么了。所以这里设计很重要，不设计的代码今天不死也是拖到明天去死，不管我们在盒马待多久，不能给未来的兄弟挖坑啊。在我负责的模块里，我们完整地应用了 DDD 的方式去完成整个系统，其中有我们自己的思考和改变，在这里我想给大家分享一下，他山之石可以攻玉，大家可以借鉴。 领域模型探讨 1. 领域模型设计：基于数据库 vs

DMVP，全称DDD-MVP，是基于领域驱动设计（DDD）搭建的业务框架，整体设计符合DDD领域模型的规范，业务上达成了领域模型和代码的一一映射，技术上达成了高内聚低耦合的架构设计，开发人员不需要关注DDD框架设计，只需专心写业务逻辑即可，节约了人力成本。 DMVP框架特点： 1：通过页面简单配置，即可生成规范的DDD战术框架，只需在框架内实现业务逻辑即可。 2：代码和领域模型的统一对应，制定了领域模型和代码的对应规范，做到代码即领域模型，即业务。 3：框架由多年实战经验总结而成，实战过大型互联网分布式项目，期间框架历经多次改版。 4：框架设计思想和套路属于DDD实战先驱前列。 DMVP框架架构设计： DMVP框架使用： 目前使用比较简单，准备好业务的领域模型，在页面上进行录入，点击生成代码，即可生成标准DDD Maven工程，本地导入即可开发，使用步骤： 1：登陆框架首页，进行领域模型的录入。 2：点击生成代码按钮，后台生成代码框架后，浏览器自动下载，导入 idea，开始业务编码。 示例部分截图如下： 代码生成完成之后截图如下： 如何获得DMVP框架，扫描下方二维码即可获得，是收费的，付费之后你将获得4大特权： 1：整套框架的使用权限(非商用)，视频直播讲解DMVP，知识星球有问必答(晚上或周末集中作答，好的提问会有代码演示)。 2：多年DDD战略战术套路总结，每周一篇

目录 面试的时候，面试官问：用户在电商网站中购买成功了，那么它在微服务中经历了什么？你该如何作答？ 简单粗暴，四个模块 DDD 领域驱动设计 微服务结合DDD 实施DDD的关键 构建我们电商系统的上下文映射图 时序图 微服务技术栈选型 微服务技术栈选型 微服务 ： 利和弊 利： 弊（或者说挑战）： 微服务怎么做逻辑分层 微服务基础服务层 微服务聚合服务层 分布式事务 CAP定理 BASE理论 MQ消息事务-RocketMQ TCC方案 熔断限流隔离降级 熔断 隔离 限流 降级 hystrix 集中式配置中心 携程的apollo 调用链监控&日志 docker + kubernetes 部署到生产，预估容量 评估访问量 评估平均访问量qps 评估高峰qps 评估系统，单机极限qps 面试的时候，面试官问：用户在电商网站中购买成功了，那么它在微服务中经历了什么？你该如何作答？ 当我傻啊，用户在电商网站购买成功，还在微服务中，那肯定就是有一套微服务架构的电商系统。 设计一套电商系统还不简单 简单想象一下，既然是一个电商系统，有用户去购买，就肯定得有一个 用户模块 ，购买什么东西总不是西北风吧，购买肯定是商品吧，省掉购物车，就得有 商品模 块吧，商品总得有库存吧，库存就暂时跟商品放一起吧，什么仓储物流先别管，就当作是虚拟商品好了，反正题目也没说不能是虚拟商品^_^，购买成功了

导读： 对于一个架构师来说，在软件开发中如何降低系统复杂度是一个永恒的挑战，无论是 94 年 GoF 的 Design Patterns ， 99 年的 Martin Fowler 的 Refactoring ， 02 年的 P of EAA ，还是 03 年的 Enterprise Integration Patterns ，都是通过一系列的设计模式或范例来降低一些常见的复杂度。但是问题在于，这些书的理念是通过技术手段解决技术问题，但并没有从根本上解决业务的问题。所以 03 年 Eric Evans 的 Domain Driven Design 一书，以及后续 Vaughn Vernon 的 Implementing DDD ， Uncle Bob 的 Clean Architecture 等书，真正的从业务的角度出发，为全世界绝大部分做纯业务的开发提供了一整套的架构思路。 前言 由于 DDD 不是一套框架，而是一种架构思想，所以在代码层面缺乏了足够的约束，导致 DDD 在实际应用中上手门槛很高，甚至可以说绝大部分人都对 DDD 的理解有所偏差。举个例子， Martin Fowler 在他个人博客里描述的一个 Anti-pattern， Anemic Domain Model （贫血域模型）在实际应用当中层出不穷，而一些仍然火热的 ORM 工具比如 Hibernate