读后感:关于领域驱动设计,过去多多少少用到一些.所以,这本精简版看起来很快,很多概念很熟悉,它帮助我把散乱的知识串起来.最后,Eric Evans谈到一点,本来软件的发展是向着处理复杂的业务逻辑走的,但突然Web技术的出现,造成了这个方向的停滞.顿时感觉商业的力量真的很大,市场需要什么,技术就往哪个方向走. 电子书: dddquickly-chinese-version.pdf

本书是Eric Evans对他自己写的<领域驱动设计-软件核心复杂性应对之道>的一本字典式的参考书,可用于快速查找<领域驱动设计>中的诸多概念及其简明解释. DDD到目前为止知道的人越来越多了,正巧今天在自己的书单中翻出这本尘封已久的电子版,网上查了下也没有人来翻译,所以近期就准备把这个本书翻译一下,也锻炼下自己蹩脚的英文水平,如有错误欢迎及时指出.>_<|||   内容不多就50多页,我每次按一个章节来发,敬请期待.由于第一章主要是讲一些致谢什么的,这次一起发2章(传

Introduction Many approaches to object oriented modeling tend not to scale well when the applications grow in size and complexity. Context Mapping is a general purpose technique, part of the Domain Driven Design (DDD) toolkit, helps the architects an

本文算是<领域驱动设计>这本书的读书笔记,加上自己的一些读后感.网上有很多这本书的读书笔记,但是都是别人的,不如自己总结的理解深刻.建议大家在读这本书时结合<实现领域驱动设计>一起看,同时,一定要去实际建模和编码,理论联系实际才能得其精髓. 定义 DDD是Domain driven design(领域驱动设计)的简称,是一种软件设计和开发的方法论,特别适用于复杂业务领域软件设计和开发.可参考wiki: Domain-driven_design 核心 将所有业务逻辑内聚到业务领域(d

阅读目录 前言 场景1的思考 场景2的思考 避坑方式 实践 结语 一.前言 在上一篇中(如何一步一步用DDD设计一个电商网站(八)—— 会员价的集成),有一行注释的代码: public interface IRoleDiscountRelationRepository// : IRepository<RoleDiscountRelation> { RoleDiscountRelation Get(string roleId); } 其中涉及的到问题是关于值对象的持久化问题.是的,由于我们之前的

阅读目录 前言 建模 实现 结语 一.前言 前面几篇已经实现了一个基本的购买+售价计算的过程,这次再让售价丰满一些,增加一个会员价的概念.会员价在现在的主流电商中,是一个不大常见的模式,其带来的问题是: 1.加大了运营的复杂度,会员价如何与促销结合,比如应在折前运用还是折后运用等. 2.如果是折前那么需要考虑满减类型促销的金额满足点门槛反而相对来说是提高了. 3.如果是折后那么享受了多重优惠,成本控制的时候需要考虑进去. 在我们这个练手的Demo中暂时决定让会员价在折后运用,并且仅在不满足满减促

 阅读目录 前言 回顾 梳理 实现 结语 一.前言 之前的文章中已经涉及到了购买商品加入购物车,购物车内购物项的金额计算等功能.本篇准备把剩下的购物车的基本概念一次处理完. 二.回顾 在动手之前我对之前的购买上下文内对象做了一次回顾.先梳理一下已经在上下文内出现的领域对象,如图1所示: [图1] 在梳理的过程中,我把原来Cart.AddCartItem(string productId, int quantity, decimal price)重构为了Cart.AddCartItem(Produ

一.前言     DDD(领域驱动设计)的一些介绍网上资料很多,这里就不继续描述了.自己使用领域驱动设计摸滚打爬也有2年多的时间,出于对知识的总结和分享,也是对自我理解的一个公开检验,介于博客园这个平台也算是对DDD的推广尽了一份绵薄之力.一开始接触这个东西是在2014年,真的觉得像是发现了一片新大陆一般,对我整个程序开发视野有了新的理解,但是像[Vaughn Vernon]<实现领域驱动设计>里写的那样,景色虽好,可是自己很长一段时间内很混乱,理不清眼前的陌生世界,因为它与传统的观念完全不同

阅读目录 前言 明确业务细节 建模 实现 结语 一.前言 上一篇我们已经确立的购买上下文和销售上下文的交互方式,传送门在此:http://www.cnblogs.com/Zachary-Fan/p/DDD_6.html,本篇我们来实现售价上下文的具体细节. 二.明确业务细节 电商市场越来越成熟,竞争也越来越激烈,影响客户流量的关键因素之一就是价格,运营的主要打法之一也是价格,所以是商品价格是一个在电商中很重要的一环.正因为如此也让促销演变的越来越复杂,那么如何在编码上花点心思来尽可能的降低业务的

阅读目录 前言 如何在一个项目中实现多个上下文的业务 售价上下文与购买上下文的集成 结语 一.前言 前几篇已经实现了一个最简单的购买过程,这次开始往这个过程中增加一些东西.比如促销.会员价等,在我们的第一篇文章(如何一步一步用DDD设计一个电商网站(一)—— 先理解核心概念)中规划的上下文映射图可以看到,这些都属于一个独立的上下文(售价上下文). 二.如何在一个项目中实现多个上下文的业务 一般情况下,为了更好的分而治之,把不同的上下文作为单独的service,然后通过rpc框架(如WCF)来对其

阅读目录 前言 单元测试 纠正错误,重新出发 结语 一.前言 实际编码已经写了2篇了,在这过程中非常感谢有听到观点不同的声音,借着这个契机,今天这篇就把大家提出的建议一个个的过一遍,重新整理,重新出发,为了让接下去的DDD之路走的更好. 二.单元测试 蟋蟀兄在我的第三篇文章下面指出: 这点其实是我偷懒了,单元测试其实不单单在DDD中是一个很重要的一环,在我们崇尚敏捷,快速迭代的大背景下,有良好的单元测试模块可以保证快速迭代下的项目质量.有甚至可以使用测试先行的TDD模式. 单元测试的好处我就不多

阅读目录 前言 怎么卖 领域服务的使用 回到现实 结语 一.前言 上篇中我们讲述了“把商品卖给用户”中的商品和用户的初步设计.现在把剩余的“卖”这个动作给做了.这里提醒一下,正常情况下,我们的每一步业务设计都需要和领域专家进行沟通,尽可能的符合通用语言的表述.这里的领域专家包括但不限于当前开发团队中对这块业务最了解的开发人员.系统实际的使用人等. 二.怎么卖 如果在没有结合当前上下文的情况下,用通用语言来表述,我们很容易把代码写成下面的这个样子(其中DomainRegistry只是一个简单的工厂

一.前言 结合我们本次系列的第一篇博文中提到的上下文映射图(传送门:如何一步一步用DDD设计一个电商网站(一)—— 先理解核心概念),得知我们这个电商网站的核心域就是销售子域.因为电子商务是以信息网络技术为手段,以商品交换为中心的商务活动,一个好的核心域设计可以大大提升企业的竞争力和对市场变化的相应速度. 那么我们开始设计领域对象.对于设计领域对象的基本概念不了解的可以先阅读我的该系列第二篇文章(传送门:如何一步一步用DDD设计一个电商网站(二)—— 项目架构). 二.定义几个基类 我相信我们大

阅读目录 前言 六边形架构 终于开始建项目了 DDD中的3个臭皮匠 CQRS(Command Query Responsibility Segregation) 结语 一.前言 上一篇我们讲了DDD的核心概念(附上链接),并且设计了我们的上下文映射图,那么接下来就准备开始立项了,本篇文章的部分知识点可能对一部分人来说比较基础,可以选择性的阅读. 在这之前我们平常用的最多的应该就是3层架构了,这里也不展开描述了,大家都是在3层的陪伴下一路走来的~ DDD所使用的传统分层架构是松散分层,也就是上层可

从遇到问题开始 当人们要做一个软件系统时,一般总是因为遇到了什么问题,然后希望通过一个软件系统来解决. 比如,我是一家企业,然后我觉得我现在线下销售自己的产品还不够,我希望能够在线上也能销售自己的产品.所以,自然而然就想到要做一个普通电商系统,用于实现在线销售自己企业产品的目的. 再比如,我是一家互联网公司,公司有很多系统对外提供服务,面向很多客户端设备.但是最近由于各种原因,导致服务经常出故障.所以,我们希望通过各种措施提高服务的质量和稳定性.其中的一个措施就是希望能做一个灰度发布的平台,这个

明天就是大年三十了,今天在家有空,想集中整理一下CQRS架构的特点以及相比传统架构的优缺点分析.先提前祝大家猴年新春快乐.万事如意.身体健康! 最近几年,在DDD的领域,我们经常会看到CQRS架构的概念.我个人也写了一个ENode框架,专门用来实现这个架构.CQRS架构本身的思想其实非常简单,就是读写分离.是一个很好理解的思想.就像我们用MySQL数据库的主备,数据写到主,然后查询从备来查,主备数据的同步由MySQL数据库自己负责,这是一种数据库层面的读写分离.关于CQRS架构的介绍其实已经非常

写在前面 阅读目录: 具体业务场景 业务需求变化 "愚蠢"的应对 消息列表实现 消息详情页实现 消息发送.回复.销毁等实现 回到原点的一些思考 业务需求变化,领域模型变化了吗? 对象读取的额外思考 写在最后 领域驱动设计的核心-Domain Model(领域模型),这个大家都知道,可是,上次关于领域模型的设计分享,要追溯到两个月之前了,这中间搞了一些有的没有的东西,比如纠结于仓储等,说这些东西不重要,其实也蛮重要的,因为它是一个完整应用程序所必须要考虑的东西(Demo 除外),但是相对

写在前面 除了博文内容之外,和 netfocus 兄的讨论,也可以让你学到很多(至少我是这样),不要错过哦. 阅读目录: 迷雾森林 找回自我 开源地址 后记 毫无疑问,领域驱动设计的核心是领域模型,领域模型的核心是实现业务逻辑,也就是说,在应对具体的业务场景的时候,实现业务逻辑是领域驱动设计最重要的一环,在写这篇博文之前,先总结下之前关于 DDD(领域驱动设计)的三篇博文: 我的“第一次”,就这样没了:DDD(领域驱动设计)理论结合实践:伪领域驱动设计,只是用 .NET 实现的一个“空壳”,仅此

ABP相关岗位招聘:给热爱.NET新技术和ABP框架的朋友带来一个高薪的工作机会 ABP交流会录像视频:ABP架构设计交流群-7月18日上海线下交流会的内容分享(有高清录像视频的链接) 代码自动生成:分享一个与ABP配套使用的代码生成器源码 ABP系列文章总目录: 1.ABP总体介绍  2.ASP.NET Boilerplate入门 3.ABP分层架构 4.ABP模块系统 5.ABP启动配置 6.ABP依赖注入 7.ABP Session管理8.ABP日志管理9.ABP设置管理10.ABP领域层

去年就打算总结一下,结果新换的工作特别忙,就迟迟没有认真动手.主要内容是很多初学DDD甚至于学习很长时间的同学没有弄明白DDD是什么,适合什么情况.这世界上没有银弹,抛开了适合的场景孤立的去研究DDD,在学习过程中还可以,但是应用到实际项目时就会遇到各种坑,到头来各种妥协,我看到很多同学遇到这种情况,最后怪DDD,说DDD不实用云云.另有一些都没细了解过就抨击反对的,事实上,要想否定个东西,你总要了解了才有发言权. 一.误区 综合起来主要有一下几种误区: 1.1.DDD更高级,可以替代三层,为了