精华内容
下载资源
问答
  • DDD领域驱动设计:四层架构应用

    千次阅读 2021-12-17 09:49:21
    分层架构是运用最为广泛的一种架构模式,几乎每个软件系统都需要通过分层来隔离不同的关注点,以应对不同需求的变化,并且使得这种变化可以独立进行。 对于分层架构来说,层次越往上其抽象层次就越面向业务用户,...


    前言

    分层架构是运用最为广泛的一种架构模式,几乎每个软件系统都需要通过分层来隔离不同的关注点,以应对不同需求的变化,并且使得这种变化可以独立进行。 对于分层架构来说,层次越往上其抽象层次就越面向业务和用户,层次越往下其抽象层次就越面向技术和设备。

    一、DDD四层与传统三层区别

    我们常用的三层架构模型划分为表现层,业务逻辑层,数据访问层等,在DDD分层结构中既有联系又有区别,个人认为主要有如下异同:

    在架构设计上,在DDD分层结构中将传统三层架构的业务逻辑层拆解为应用层和领域层
    其中Application划分为很薄的一层服务,非核心的逻辑放到此层去实现,核心的业务逻辑表现下沉到领域层去实现,凝练为更为精确的业务规则集合,通过领域对象去阐述说明。
    在这里插入图片描述

    在建模方式上,DDD分层的建模思维方式有别于传统三层
    传统三层通常是以数据库为起点进行数据库分析设计,而DDD则需要以业务领域模型为核心建模(即面向对象建模方式),更能体现对现实世界的抽象。
    故在DDD分层凸显领域层的重要作用,领域层为系统的核心,包括所有的业务领域模型的抽象表达。

    在职责划分上,基础设施层涵盖了2方面内容:
    持久化功能,其中原三层架构的数据访问层下沉到基础设施层的持久化机制实现
    通用技术支持,一些公共通用技术支持也放到基础设施层去实现。


    二、四层架构详解

    在这里插入图片描述

    1.分层作用

    分层英文描述
    表现层User Interface用户界面层,或者表现层,负责向用户显示解释用户命令
    应用层Application Layer定义软件要完成的任务,并且指挥协调领域对象进行不同的操作。该层不包含业务领域知识。
    领域层Domain Layer也可称为模型层,系统的核心,负责表达业务概念,业务状态信息以及业务规则。即包含了该领域(问题域)所有复杂的业务知识抽象和规则定义。该层主要精力要放在领域对象分析上,可以从实体,值对象,聚合(聚合根),领域服务,领域事件,仓储,工厂等方面入手
    基础设施层Infrastructure Layer主要有2方面内容,一是为领域模型提供持久化机制,当软件需要持久化能力时候才需要进行规划;一是对其他层提供通用的技术支持能力,如消息通信,通用工具,配置等的实现;

    2.领域对象

    类型英文描述
    值对象value object无唯一标识的简单对象
    实体entity充血的领域模型,有唯一标识
    聚合(聚合根)aggregate实体的聚合,拥有聚合根,可为某一个实体
    领域服务service无法归类到某个具体领域模型的行为
    领域事件event不常用
    仓储repository持久化相关,与基础设施层关联
    工厂factory负责复杂对象创建
    模块module子模块引入,可以理解为子域划分

    三、编码实践

    1.代码结构

    ├─com.company.microservice
    │    │ 
    │    ├─apis   API接口层
    │    │    ├─model     视图模型,数据模型定义 vo/dto(大多数情況是一样的)
    │    │    ├─assembler    装配器,实现模型转换eg. apiModel<=> domainModel
    │    │    └─controller   控制器,对外提供(Restful)接口
    │    │ 
    │    ├─application   应用层
    │    │    ├─service  应用服务,非核心服务
    │    │    ├─task     任务定义,协调领域模型 
    │    │    └─***      others
    │    │ 
    │    ├─domain   领域层
    │    │    ├─common       公共代码抽取,限于领域层有效 
    │    │    ├─events       领域事件
    │    │    ├─model        领域模型 
    │    │    │    ├─dict    领域划分的模块,可理解为子域划分
    │    │    │    │    ├─DictVo.java       领域值对象
    │    │    │    │    ├─DictEntity.java   领域实体,充血的领域模型,如本身的CRUD操作在此处
    │    │    │    │    ├─DictAgg.java      领域聚合,通常表现为实体的聚合,需要有聚合根
    │    │    │    │    └─DictService.java  领域服务,不能归与上述模型,如分页条件查询等可写在此处
    │    │    │    ├─xxx
    │    │    │    │    ├─xxxEntity.java         
    │    │    │    │    ├─bbbAgg.java     
    │    │    │    │    └─cccAgg.java        
    │    │    ├─service      领域服务类,一些不能归属某个具体领域模型的行为
    │    │    └─factory      工厂类,负责复杂领域对象创建,封装细节 
    │    │ 
    │    ├─infrastructure  基础设施层
    │    │    ├─persistent   持久化机制
    │    │    │    ├─po           持久化对象 
    │    │    │    └─repository   仓储类,持久化接口&实现,可与ORM映射框架结合
    │    │    ├─general      通用技术支持,向其他层输出通用服务
    │    │    │    ├─config       配置类
    │    │    │    ├─toolkit      工具类  
    │    │    │    └─common       基础公共模块等
    │    │ 
    │    └─resources  
    │        ├─statics  静态资源
    │        ├─template 系统页面 
    │        └─application.yml   全局配置文件
    
    

    四、常见问题

    1.领域模型(充血模型)注入问题

    区别于传统的分层后,在domain中更多关注业务逻辑,考虑到要与spring框架集成,需要注意一个领域模型中注入的问题

    在传统分层中,controller,service,repo均注册为spring管理的bean,但是在domain层中,service一部分的业务逻辑划分到了具体的领域对象中去实现了,显然这些对象却不能注册为单例bean,因此在此处不能沿用与原来分层结构中service层中通过@Autowired or @Resource等注入接口

    关于这个问题,此处建议使用ApplicationContext实现

    即通过一个工具类 ApplicationContextUtils 实现 ApplicationContextAware获取bean的方法,即 getBean()方法,然后我们就可以在我们的领域模型中直接应用该工具类来获取Spring托管的singleton对象,xxxRepo=ApplicationContextUtils.getBean(“xxxRepository”)


    结尾

    • 感谢大家的耐心阅读,如有建议请私信或评论留言。
    • 如有收获,劳烦支持,关注、点赞、评论、收藏均可,博主会经常更新,与大家共同进步
    展开全文
  • 通过《多维度规划业务架构》,我们获得了由业务领域-业务组件-业务服务三个层次组成的业务架构。虽然是架构,但其本质仍然属于问题空间,其目的在于真实地探索问题空间,了解我们要解决什么样的问题。我们用到“分解...

    通过《多维度规划业务架构》,我们获得了由业务领域-业务组件-业务服务三个层次组成的业务架构。虽然是架构,但其本质仍然属于问题空间,其目的在于真实地探索问题空间,了解我们要解决什么样的问题。我们用到“分解”的方法,并非在解决问题,而是希望通过横向分层与纵向切分让问题空间变得更小,降低业务复杂度罢了。

    这种分解层次体现为:

    • 业务领域是对目标系统之系统范围进行划分,划分依据为价值高低

    • 业务组件是对业务领域的划分,划分依据在于业务相关性

    • 业务服务是对业务组件的划分,划分依据在于领域模型的知识语境

    领域驱动进行的业务分解,既是对问题空间的探索,又自然地暗合确定解决方案的思路。由于有清晰的边界存在,这一做法并未混淆问题空间与解空间,却天然地搭建了一种映射方法,使得我们能够以较小成本将业务架构映射为IT架构中的应用架构。

    映射体系如下图所示:

    图片

    在图右侧所示的应用架构中,我旗帜鲜明地标记了前台、中台与后台,意味着我对应用架构的划分遵循了中台战略规划的思想。

    我所理解的“中台”,满足以下定义:

    • 中台是企业数字化转型的能力复用战略规划体系

    • 中台是演进式的能力复用战略动态规划过程

    显然,中台不是产品,也不是平台,而是一种规划体系。在企业架构的应用架构中,中台仅占据了中间代表了“能力服务层”的一部分,体现为由应用组件构成的能力中心。所谓的“能力复用战略动态规划过程”,就是在企业战略愿景的指导下,以能力复用为最终目的:

    • 对于产品服务层,通过识别变化频率与复用粒度,逐步将前台的产品特性沉淀为可复用的业务能力中心

    • 对于基础服务层,通过识别企业IT资产,逐步从后台的工具与框架中提炼出可复用的业务能力中心

    换言之,中台不是独立的,随着时间的推移,应形成前台、中台和后台(统称为“三台”)职责之间联动;中台也不是静态不变的,同样随着时间的推移,三台的边界发生动态变化。

    之所以要为应用架构建立中台,是以复用为目的,提升研发的效率和质量。能力中心的构成,使得整个企业的系统架构可以打破烟囱系统天然构成的壁垒,也有利于它的快速演化,适应企业高速发展的业务需要。

    中台战略体系保留了前台,主要是为了适应创新型产品的演变。前台的设计属于产品思维的范畴,因为它牵涉到快速试错的成本,没有时间和成本考虑对复用能力的沉淀,然而,对于中台已经具备的能力中心,不妨取“拿来主义”的态度,直接复用。如此既保证了快,又保证了稳。

    在我认为的“三台”中,后台并非基础设施,它同样属于业务范畴。从Pace-Layer Architecture的角度讲,后台提供的业务其区别主要在于它的变化频率更低,甚至可能几乎不变;从领域驱动设计的子领域角度讲,后台提供的业务更加通用,以至于考虑购买而非自己构建的方式实现。

    如果后台稳定地提供了业务支撑,其收益高于维护成本,则不必一定要将其提炼为能力中心,甚至于它就是一个或多个相对独立而封闭的IT系统,对它的改造存在诸多阻力,改造成本极高,就得允许在企业IT系统生态中继续存在这样的遗留烟囱系统。

    不管是前台的产品,还是中台的能力中心,抑或后台的工具或框架,其解决方案皆由应用组件构成,它由业务组件映射而得。本质上,业务组件与应用组件都是限界上下文,但前者对应的限界上下文只考虑了业务边界,后者对应的限界上下文在此基础上继续深化,分别考虑团队角度的工作边界和技术角度的应用边界,进一步梳理限界上下文的边界,使其与应用架构相匹配。为示区分,我将其命名为“应用组件”。

    应用组件与限界上下文也有不同之处。在领域驱动设计中,限界上下文确定的是逻辑边界,而在应用架构中,还需要确定它的物理边界。物理边界的确定是从质量属性角度考虑的,例如对可扩展性、可伸缩性、低延迟、高并发的响应,技术栈的限制,资源独立性的要求,可以确定该应用组件究竟应定义为服务(Service),还是库(library)。

    通常,中台能力中心的应用组件应考虑微服务化,后台工具或框架则不然,大多数时候,定义为库可能更合适。对于前台,可以考虑一个产品对应一个微服务,也可以考虑一个产品的特性对应一个微服务。这取决于前台产品的粒度。

    业务架构中纯粹表达业务的业务服务,在映射到应用架构时,被定义为应用组件需要公开在外的服务接口,我将其称之为“服务契约”,目的是体现服务调用者与服务提供者之间的一种”契约“关系。

    一个业务服务映射到解空间,会定义一个服务契约;反之,一个服务契约却未必对应问题空间的业务服务——因为业务服务中的一个执行步骤也可能映射为一个服务契约。应用组件之间存在协作关系,根据业务服务的定义,如果一个业务服务的某个执行步骤由另外一个应用组件提供,就需要将其定义为另一个服务契约,但它并非业务服务。例如,“提交订单”业务服务对应于订单应用组件,需要对外公开”提交订单“的服务契约;在执行提交订单的流程时,需要验证库存,该功能由库存应用组件承担。由于订单应用组件会调用它,因而需要对外公开”验证库存“的服务契约,但”验证库存“并非一个业务服务,如下图所示:

    图片

    业务服务属于问题空间的范畴,服务契约属于解空间的范畴,如此才是合理的。

    服务契约对应于我提出的《菱形对称架构》中的北向网关。若应用组件为服务,则对应远程服务;为库,则对应本地服务。它们都不属于领域层的内容。业务服务的需求表现为业务服务规约,它的输入成为领域分析建模的基础;服务契约需要构成菱形对称架构的角色构造型共同协作完成,利用服务驱动设计可以驱动出领域设计模型,进而对其进行建模实现。

    从产品/能力中心/工具/框架到应用组件,再从应用组件到服务契约,都有领域驱动设计的对应模式或方法去实现,由此就能实现应用架构的真正落地。若按照中台战略思想规划应用架构,意味着中台的落地也有了可供参考的实现过程与方法。

    当然,通常所谓的”中台“,都会建立双中台,即业务中台和数据中台。这里参考了领域驱动设计的方法,针对的是业务中台的落地,亦可以理解为是应用架构的微服务化。至于数据中台,它关注的是全域数据的生命周期管理、数据资产的梳理与建设、全域数据分析与数据智能挖掘的数据服务,其着眼点显然和业务中台有着天壤之别,需要另外的设计方法与实现手段。

    ❀❀❀

    展开全文
  • 企业集成平台的核心是企业集成架构,包括信息、过程、应用集成的架构。 17.1 企业集成平台 1. 企业集成平台(Enterprise Integration Platform,EIP) EIP技术是近年来用于企业信息系统集成的一种先进的计算机...

    涉及单选题及案例分析题。已阅第17小时和教程

    企业集成平台的核心是企业集成架构,包括信息、过程、应用集成的架构。

    17.1 企业集成平台

    1. 企业集成平台(Enterprise Integration Platform,EIP)

    EIP技术是近年来用于企业信息系统集成的一种先进的计算机软件技术,其目的是能够根据业务模型的变化快速地进行信息系统的配置和调整,保证不同系统、应用、服务或操作人员之间顺畅地互操作,进而提高企业适应市场变化的能力,使企业能够在复杂多变的市场环境中生存。

    2. 企业集成平台概念的提出和发展

    来自于企业应用需求(企业内部信息系统越来越多)和计算机技术发展两方面的驱动。

    3. 实现企业集成的技术

    • (早先)点到点集成方式:通过在不同应用间开发一对一的专用接口实现应用之间的数据集成。优点:直观,企业应用数量少时易实现。缺点:工作量大、维护费用高、升级扩展困难;不易标准化、系统管理困难(接口太多)、只能解决应用系统间的数据集成问题,难以支持过程集成和应用间的协调
    • 企业集成平台:为了克服点对点集成方式的缺点,于是提出了企业集成平台

    4. 企业集成平台的应用架构

    通过企业集成平台进行通信和数据交换,实现广义范围内和深层次上的企业资源共享和集成。

    5. 狭义与广义的集成平台

    狭义的集成平台是指一个软件平台,它为企业内多个应用系统或系统之间的集成互操作提供所需的通用服务,达到

    展开全文
  • 在DDD的项目实践中,我们会使用一些常用的架构模式,来进行系统架构的合理设计。  以下是DDD常用架构模式: DDD分层架构 整洁架构 六边形架构 DDD分层架构 vs 整洁架构 vs 六边形架构 Event ...

    在DDD的项目实践中,我们会使用一些常用的架构模式,来进行系统架构的合理设计。 

    以下是DDD常用架构模式:

    • DDD分层架构
    • 整洁架构

    • 六边形架构

    • DDD分层架构 vs 整洁架构 vs 六边形架构

    • Event Driven 架构

    • CQRS(Command Query Responsibility Segregation) 架构

    • 微服务内领域事件设计模式

    • 微服务间领域事件设计模式

    DDD分层架构

    DDD 分层架构包含用户接口层、应用层、领域层和基础层。

    分层架构的一个重要原则是每层只能与位于其下方的层发生耦合

    分层架构可以简单分为两种,即严格分层架构和松散分层架构。在严格分层架构中,某层只能与位于其直接下方的层发生耦合,而在松散分层架构中,则允许某层与它的任意下方层发生耦合。

    分层架构的优点,Martin Fowler在《Patterns of Enterprise Application Architecture》一书中给出了答案:

    1. 开发人员可以只关注整个结构中的某一层。
    2. 可以很容易的用新的实现来替换原有层次的实现。
    3. 可以降低层与层之间的依赖。
    4. 有利于标准化。
    5. 利于各层逻辑的复用

    适当的分层体系结构将开发层面进行隔离,这些层不受其他层的更改的影响,从而使重构更加容易。划分任务并定义单独的层是架构师面临的挑战。当需求很好地适应了模式时,这些层将易于解耦或分层开发。

    使用场景:

    • 需要快速构建的新应用程序
    • 需要严格的可维护性和可测试性标准的应用

    整洁架构

    整洁架构又名“洋葱架构”。整洁架构的层就像洋葱片一样,它体现了分层的设计思想。在整洁架构里,同心圆代表应用软件的不同部分,从里到外依次是领域模型、领域服务、应用服务和最外围的容易变化的内容,比如用户界面和基础设施。

    整洁架构最主要的原则是依赖原则它定义了各层的依赖关系,越往里依赖越低,代码级别越高,越是核心能力。外圆代码依赖只能指向内圆,内圆不需要知道外圆的任何情况。

    在洋葱架构中,各层的职能是这样划分的

    • 领域模型实现领域内核心业务逻辑,它封装了企业级的业务规则。领域模型的主体是实体,一个实体可以是一个带方法的对象,也可以是一个数据结构和方法集合。
    • 领域服务实现涉及多个实体的复杂业务逻辑
    • 应用服务实现与用户操作相关的服务组合与编排,它包含了应用特有的业务流程规则,封装和实现了系统所有用例。
    • 最外层主要提供适配的能力,适配能力分为主动适配和被动适配。主动适配主要实现外部用户、网页、批处理和自动化测试等对内层业务逻辑访问适配。被动适配主要是实现核心业务逻辑对基础资源访问的适配,比如数据库、缓存、文件系统和消息中间件等。
    • 红圈内的领域模型、领域服务和应用服务一起组成软件核心业务能力

    六边形架构

    六边形架构又名“端口适配器架构”。

    六边形架构的核心理念是:应用是通过端口与外部进行交互的。

    六边形架构将系统分为内六边形和外六边形两层,这两层的职能划分:

    • 红圈内的六边形实现应用的核心业务逻辑;
    • 外六边形完成外部应用、驱动和基础资源等的交互和访问,对前端应用以 API 主动适配的方式提供服务,对基础资源以依赖倒置被动适配的方式实现资源访问

    DDD分层架构 vs 整洁架构 vs 六边形架构

    三种微服务架构模型的对比和分析

    • 虽然 DDD 分层架构、整洁架构、六边形架构的架构模型表现形式不一样,但这三种架构模型的设计思想正是微服务架构高内聚低耦合原则的完美体现,而它们身上闪耀的正是以领域模型为中心的设计思想
    • 架构模型通过分层的方式来控需求变化从外到里对系统的影响,从外向里受需求影响逐步减小。
    • 面向用户的前端可以快速响应外部需求进行调整和发布,灵活多变
    • 应用层通过服务组合和编排来实现业务流程的快速适配上线,减少传导到领域层的需求,使领域层保持长期稳定。

     

    事件驱动架构(Event Driven Architecture - EDA)

    事件驱动架构 (Event-driven architecture) 是一种软件架构模式。对于事件驱动系统而言,事件的捕获、通信、处理和持久保留是解决方案的核心结构。这和传统的请求驱动模型有很大不同。

    许多现代应用都采用了事件驱动设计。因为事件驱动本身是一种编程架构方法,而不是一种编程语言, 因此事件驱动应用可以用任何一种编程语言来创建。事件驱动架构可以最大程度减少耦合度,因此是现代化分布式应用架构的理想之选。

    事件驱动架构采用松散耦合方式,因为事件发起者并不知道哪个事件使用者在监听事件,而且事件也不知道其所产生的后续结果。

    可以从两个方面来理解 EDA:

    1. EDA 是一种侧重于以生成/消费为基础的异步通信的架构模式。这主要对照于传统的基于线程的同步系统。
    2. EDA 是一种以事件 (event)为核心,提供事件产生,路由,消费已经结果回调等机制的架构模式。

    介绍一个保险承保业务过程中有关领域事件驱动架构的例子。

    一个保单的生成,经历了很多子域、业务状态变更和跨微服务业务数据的传递。这个过程会产生很多的领域事件,这些领域事件促成了保险业务数据、对象在不同的微服务和子域之间的流转和角色转换。

    在下面这张图中,列出了几个关键流程,用来说明如何用领域事件驱动设计来驱动承保业务流程

     

     

    CQRS(Command Query Responsibility Segregation) 架构

    命令查询的责任分离Command Query Responsibility Segregation (简称CQRS)模式是一种架构体系模式,能够使改变模型的状态的命令和模型状态的查询实现分离

    本质上,CQRS是一种读写分离的机制

    两种实现方式:

    1. CQ 两端数据库共享, CQ 两端只是在上层代码上分离; 这种做法,带来的好处是可以让我们的代码读写分离,更好维护,且没有 CQ 两端的数据一致性问题,因为是共享一个数据库的。这种架构很实用,既兼顾了数据的强一致性,又能让代码好维护。
     

    2. CQ两端数据库和上层代码都分离,然后Q的数据由C端同步过来,一般是通过Domain Event进行同步。同步方式有两种,同步或异步,如果需要CQ两端的强一致性,则需要用同步;如果能接受CQ两端数据的最终一致性,则可以使用异步。

     

    微服务内领域事件设计模式

    微服务间领域事件设计模式

    领域事件处理包括:事件构建和发布、事件数据持久化、事件总线、消息中间件、事件接收和处理等

    ----------------------------------
    大家好,我是流水,一个资深的IT从业人员和架构师. 非常高兴您能搜索到,并看到这篇文章,希望这篇文章的内容能给您带来新的知识和帮助。

    也欢迎扫描以下的二码或微信搜索 “superxtech”,关注我的微信公众号 , 我会把更多更好的IT领域技术知识带给您!

    图片

    ----------------------------------

     

     

    展开全文
  • DDD领域驱动设计:CQRS架构模式

    千次阅读 多人点赞 2021-11-04 16:41:01
    而在实践过程中必然会面临许多的问题,「模式」是系统架构领域中一种常见的手段,能够帮助开发人员与架构师在遭遇某种较为棘手,或是陌生的问题时,参考已有的成熟经验与解决方案,从而优雅的解决自己项目中的问题。...
  • DDDDDD(Domain Driven Design,领域驱动设计)作为一种软件开发方法,它可以帮助我们设计高质量的软件模型。在正确实现的情况下,我们通过DDD完成的设计恰恰就是软件的工作方式。UL(Ubiquitous Language,通用语言)是...
  • 想知道如何设计大型企业级的系统吗?在开始主要的代码开发之前,我们必须选择一种合适的体系架构,它将为我们提供所需的功能质量属性。因此,在将它们应用到我们的设计之前,应该先了解不同的体系结构...
  • DDD 分层架构包含用户接口层、应用层、领域基础层。通过这些层次划分,我们可以明确微服务各层的职能,划定各领域对象的边界,确定各领域对象的协作方式。。 DDD的分层架构如图:从上到下依次是:用户接口层、...
  • 2003年,DDD(领域驱动设计)这一软件开发的方法与愿景经由建模专家 Eric Evans 的经典著作Domain-Driven Design: Tackling Complexity in the Heart of Software 正式面世,当即获得了广泛关注高度评价。...
  • 常用7种软件架构模式

    2020-12-23 09:35:57
    架构模式是对给定上下文的软件架构中常见问题的一种通用的可复用的解决方案。 一种模式就是特定上下文的问题的一种解决方案。 大体上,主要有下面这7种架构模式: 分层架构; 多层架构; 管道 - 过滤器架构; 客户端 - ...
  • 1、微服务架构介绍 微服务架构(Microservice ...概念:把一个大型的单个应用程序服务拆分为数个甚至数十个的支持微服务,它可扩展单个组件而不是整个的应用程序堆栈,从而满足服务等级协议。 定义:围绕业务领域
  • 五大主流软件架构模式1.五大主流软件架构模式2.详细介绍1.微内核模式2.微服务模式3.分层架构模式4.基于事件(事件驱动)的模式5.给予空间的模式 1.五大主流软件架构模式 微内核、微服务、分层架构、基于事件(事件驱动...
  • 想知道如何设计大型企业级的系统吗?在开始主要的代码开发之前,我们必须选择一种合适的体系架构,它将为我们提供所需的功能质量属性。因此,在将它们应用到我们的设计之前,应该先了解不同的体系结构...
  • 在微服务(Microservices)架构实践中,架构设计借用了DDD中的一些概念技术,比如一个微服务对应DDD中的一个限界上下文(Bounded Context);在微服务设计中应该首先识别出DDD中的聚合根(Aggregate Root);还有...
  • 云原生架构本身作为一种架构,也有若干架构原则作为应用架构的核心架构控制面,通过遵从这些架构原则可以让技术主管架构师在做技术选择时不会出现大的偏差。 1.1 服务化原则 当代码规模超出小团队的合作范围时,...
  • DDD之应用架构

    千次阅读 2021-05-02 12:29:55
    一,前言 之所以写这些文章,很大程度上,是因为阅读了阿里技术专家的文章,读完之后,对我内心触动很大,文章多出引用了阿里技术文章的内容,仅作为个人学习用途,也是作为技术人...所谓应用架构,个人理解,更可以指
  • 上一篇推文:8 年开发,连登陆接口都写这么烂...你是否想知道企业大规模系统是如何设计的?在软件开发开始之前,我们必须选择一个合适的架构,能提供所需的功能质量特性。因此,在将架构应用到我...
  • 三层架构模式介绍三层架构模式:三层架构(3-tier architecture) 通常意义上的三层架构就是将整个业务应用划分为:界面层(User Interface layer)、业务逻辑层(Business Logic Layer)、数据访问层(Data ac...
  • 置顶/星标公众号????,硬核文章第一时间送达!本文主要介绍了几种主要的软件架构模式架构模式是对给定上下文的软件架构中常见问题的一种通用的可复用的解决方案。一种模式就是特定上下文的问题的...
  • 架构师必须掌握的重要微服务架构设计模式

    千次阅读 热门讨论 2021-03-02 22:36:29
    这边文章主要介绍一下微服务架构及其重要的设计模式,并介绍每种模式的优点,缺点,适用场景不适用的场景,及其可用实现的技术有哪些。 微服务架构设计模式列表: 独享数据库(Database per Microservice) ...
  • 数字化让我们利用数字技术来改变商业模式,改造企业流程,给出行动方案,提供新的业务价值机会。 但到底怎样来进行数字化转型呢? 很多企业在数字化转型过程中感到迷茫困惑。 有些企业的数字化主要在战略层面,...
  • 企业应用企业软件应用中的一个类别,被称为软件开发领域的“明珠”。典型的企业应用通常可以分为三个大类,即支撑企业核心业务的应用系统(如生产制造业的MES、交通运输业的TMS)、涵盖企业全流程的大规模综合...
  • 物联网的应用模式

    2021-08-31 22:03:58
    这些应用模式并不是专属于物联网应用领域,而是在物联网应用领域,放大了这些应用模式的效果与价值。 简单说一下,文章中提及的工业物联网项目下的风机监测。 工业物联网项目下的风机监测系统,是通过一系列传感器...
  • Martin Fowler 作为 《重构 : 改善既有代码的设计》、《企业应用架构模式》等著作的作者; 敏捷软件开发宣言创作者之一; MVVM模式诞生时参考引用的技术专家。 Martin Fowler给的MVC模式图如下: 上面知名公司A...
  • 微服务架构设计模式笔记--第四章 微服务架构中的业务逻辑设计1. 业务逻辑的组织模式1.1 使用事务脚本模式设计业务逻辑1.2 使用领域模型模式设计业务逻辑1.3 关于领域驱动设计2. 使用聚合模式设计领域模型...企业应用
  • 软件架构设计分层模型构图思考

    千次阅读 2021-03-20 00:17:33
    点击上方“朱小厮的博客”,选择“设为星标”后台回复"书",获取后台回复“k8s”,可领取k8s资料今天谈下架构设计中的分层思维分层模型以及基于分层思维下的架构构图逻辑。架...
  • 企业级业务架构设计理论与方法

    千次阅读 2021-04-07 00:50:38
    本文首发微信公众号:码上观世界。导读企业架构转型是企业数字化转型的重要抓手实施手段,而企业业务架构设计是企业架构设计的重要内容决定部分,是衔接企业战略IT项目的桥梁。而如何通过业务架...
  • 我们都自诩面向对象编程,熟悉的使用Action/Service/DAO三层架构模式,然而随着业务日益复杂,代码越来越臃肿,这时感觉之前面向对象的理论也毫无用武之地。造成这种局面的原因很大程度是我们忽视了业务建模设计的...
  • 在讨论DDD分层架构模式之前,我们先一起回顾一下DDD分层架构的相关知识。 领域驱动设计DDD在战术建模上提供了一个元模型体系(如下图),通过这个元模型我们会对战略建模过程中识别出来的问题子域进行抽象,而...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 219,451
精华内容 87,780
关键字:

企业应用架构模式和领域