- 博客(194)
- 资源 (4)
- 收藏
- 关注
RSS订阅
原创 DDD领域驱动设计-DDD开源框架xtoon-boot
基于DDD领域模型并支持SaaS平台的企业级开发脚手架.开源地址：https://gitee.com/xtoon/xtoon-boot官网：http://xtoon-boot.xiangtoon.com在线演示：http://xtoon-boot.demo.xiangtoon.com如果有什么问题或建议可以加群（QQ：130950009），交流技术，分享经验。为何选择xtoon-boot解决编写过程式和事务代码，造成后期维护逻辑混乱、维护成本高的痛点； 抛弃MVC框架，拥抱更.
2021-03-04 14:17:13
5826
5
原创 访问者模式 (Visitor Pattern)
访问者模式（Visitor Pattern）是一种行为型设计模式，用于将算法与其作用于的对象结构分离。这种模式主要用于执行操作或应用过程，这些操作需要在不同类型的对象上执行，同时避免让这些对象的类变得过于复杂。关键组成部分访问者（Visitor）一个接口或抽象类，定义了对不同类型元素（Element）的访问操作。实现了每种类型元素的操作，是将操作逻辑从元素类中分离出来的关键所在。元素（Element）定义了一个接受访问者的方法（通常为accept），该方法允许访问者对象访问元素。
2023-11-24 17:25:23
138
原创 模板方法模式 (Template Method Pattern)
模板方法模式（Template Method Pattern）是一种行为型设计模式，它在一个方法中定义一个算法的骨架，将一些步骤的实现延迟到子类。通过这种方式，模板方法允许子类在不改变算法结构的情况下，重新定义算法的某些特定步骤。抽象类（Abstract Class）：定义模板方法，以及算法的骨架。它可以包含具体方法、抽象方法和钩子（hook）方法。具体子类（Concrete Class）：实现抽象类中定义的抽象方法和钩子方法，从而完成算法中特定子部分的实现。
2023-11-24 17:25:08
138
原创 策略模式 (Strategy Pattern)
策略模式（Strategy Pattern）是一种行为型设计模式，它定义了算法家族，分别封装起来，让它们之间可以互相替换。策略模式使得算法的变化独立于使用算法的客户。上下文（Context）：用来维护对某个策略对象的引用。策略接口（Strategy）：定义了一个公共接口，各种不同的算法以不同的方式实现这个接口。具体策略（Concrete Strategy）：实现策略接口的具体算法。
2023-11-24 17:24:49
150
原创 状态模式 (State Pattern)
状态模式（State Pattern）是一种行为型设计模式，它允许一个对象在其内部状态改变时改变它的行为。这种模式将每个状态的行为封装到对应的状态类中，使得上下文（Context）的行为随着其内部状态的改变而改变，看起来像是改变了其类。
2023-11-24 17:24:29
71
原创 观察者模式 (Observer Pattern)
观察者模式（Observer Pattern）是一种行为型设计模式，允许一个对象（称为主题）维护一系列依赖于它的对象（称为观察者），并在主题状态改变时自动通知它们。这种模式主要用于实现事件处理系统、消息发布/订阅系统等，能够促进对象间的松耦合。
2023-11-24 17:24:12
51
原创 备忘录模式 (Memento Pattern)
备忘录模式（Memento Pattern）是一种行为型设计模式，它提供了一种方式来恢复对象到其先前状态。在不破坏对象封装性的前提下，备忘录模式捕获并外部化对象的内部状态，以便稍后可以将对象恢复到这个状态。这个模式通常用于实现撤销操作或实现事务功能，其中的状态回滚相当于撤销。发起人（Originator）：负责创建一个包含其当前内部状态的备忘录，并可以使用备忘录恢复其内部状态。备忘录（Memento）：负责存储发起人的内部状态，并防止发起人以外的对象访问备忘录。负责人（Caretaker）
2023-11-24 17:23:56
69
原创 中介者模式 (Mediator Pattern)
中介者模式（Mediator Pattern）是一种行为型设计模式，它通过引入一个中介对象来简化多个对象之间的复杂交互。这种模式的目的是减少通信对象之间的直接引用，从而减少它们之间的耦合度，使得可以独立地改变它们之间的交互。中介者（Mediator）接口：定义了通信的接口。具体中介者（Concrete Mediator）：实现中介者接口，并协调各个对象之间的交互。同事类（Colleague）：需要通信的对象，它们不直接交互，而是通过中介者来进行交互。
2023-11-24 17:23:39
49
原创 迭代器模式 (Iterator Pattern)
迭代器模式（Iterator Pattern）是一种行为型设计模式，用于顺序访问集合对象的元素，而无需知道集合对象的底层表示。迭代器模式将遍历集合的责任从集合对象转移到迭代器对象上，这简化了集合接口和实现，同时也使得遍历不同的集合类型统一和标准化。迭代器（Iterator）接口：定义访问和遍历元素的接口。具体迭代器（Concrete Iterator）：实现迭代器接口，并负责遍历集合的具体对象。集合（Aggregate）接口：定义创建迭代器对象的接口。
2023-11-24 17:23:21
65
原创 解释器模式 (Interpreter Pattern)
解释器模式（Interpreter Pattern）是一种行为型设计模式，用于定义一种语言的语法表示，并提供一个解释器来处理这种语法。这种模式用于实现语言解释器，通常用于专业领域或复杂文本处理中。在解释器模式中，通常会为语言的每个规则定义一个类。抽象表达式（Abstract Expression）：定义解释操作的接口，通常包含一个解释方法。终结符表达式（Terminal Expression）：实现与文法中的终结符相关的解释操作。非终结符表达式（Nonterminal Expression）
2023-11-23 11:11:00
429
原创 命令模式 (Command Pattern)
命令模式（Command Pattern）是一种行为型设计模式，它将一个请求封装为一个对象，从而允许用户使用不同的请求、队列或日志来参数化其他对象。命令模式也支持可撤销的操作。主要目的是将命令的发送者和接收者解耦，引入了命令对象来在发送者和接收者之间充当中介。命令（Command）接口：声明执行操作的接口。具体命令（Concrete Command）：实现命令接口，定义了接收者和行为之间的绑定关系。调用者通过执行命令来执行相应的操作。接收者（Receiver）：知道如何实施与执行一个请求相关的操作。
2023-11-23 11:10:17
523
原创 责任链模式 (Chain of Responsibility Pattern)
责任链模式是一种行为型设计模式，用于在对象间建立一条处理请求的链。它允许多个对象有机会处理请求，从而减少请求的发送者和接收者之间的耦合。在责任链模式中，每个接收者包含对另一个接收者的引用，形成一条链。如果一个对象不能处理请求，它会将请求传递给链中的下一个对象，直至链的末端。责任链模式由多个处理器（或接收者）组成，每个处理器决定自己是否处理请求或将其传递给链上的下一个处理器。这种模式实现了发送者和接收者之间的解耦，同时允许动态地调整链中的处理器。处理器（Handler）
2023-11-23 11:09:34
676
原创 代理模式 (Proxy Pattern)
代理模式（Proxy Pattern）是一种结构型设计模式，它通过提供一个代理（或称代表）对象来控制对另一个对象的访问。这种模式创建了一个代理对象，用来代表实际对象的功能，从而可以在不直接访问实际对象的情况下进行操作。代理模式的核心思想是将客户端与实际执行功能的对象分离，引入一个中介层（代理层），由代理对象来决定是否和如何访问实际对象。这种间接层可以用于多种目的，比如控制访问、延迟初始化、实现安全检查、添加额外的功能（例如日志记录、事务处理等）。主题（Subject）接口。
2023-11-23 11:08:48
442
原创 享元模式 (Flyweight Pattern)
享元模式（Flyweight Pattern）是一种结构型设计模式，用于优化性能和内存使用。它通过共享尽可能多的相似对象来减少内存占用，特别是在有大量对象时。这种模式通常用于减少应用程序中对象的数量，并在多个对象间共享尽可能多的状态。内在状态（Intrinsic State）这部分状态是对象共享的。享元对象的内在状态不依赖于享元对象的上下文，即它们是不变的。这使得一个享元对象可以在不同的上下文中共享。外在状态（Extrinsic State）
2023-11-23 10:34:53
303
原创 外观模式 (Facade Pattern)
外观模式（Facade Pattern）是一种结构型设计模式，它通过提供一个统一的高层接口来简化复杂子系统或库的访问。这种模式的关键在于，它创建了一个外观类，这个类封装了对子系统的一系列复杂交互，使得子系统更易于使用和理解。简化复杂系统的接口：外观模式为复杂的内部子系统提供了一个简单的外部接口。这样，客户端在使用这些子系统时只需要与外观类交互，而不需要了解或直接访问系统的复杂内部工作。降低子系统与客户端之间的耦合度：客户端通过外观类与子系统交互，减少了与子系统内部多个模块的直接依赖。
2023-11-23 10:34:08
403
原创 装饰器模式 (Decorator Pattern)
装饰器模式（Decorator Pattern）是一种结构型设计模式，它允许动态地向一个对象添加额外的功能，而不改变其结构。这种模式通过创建一个装饰器类，用来包裹实际对象，从而提供额外的行为。在装饰器模式中，可以在运行时为对象添加新的行为，而无需修改原始对象的代码。这为扩展对象的功能提供了更大的灵活性，尤其是在遵循开闭原则（对扩展开放，对修改封闭）的情况下。组件接口（Component）：定义了一个对象接口，可以动态地给这些对象添加职责（行为）。具体组件（Concrete Component）
2023-11-23 10:33:16
317
原创 组合模式 (Composite Pattern)
组合模式（Composite Pattern）是一种结构型设计模式，用于将对象组合成树形结构以表示部分-整体的层次关系。这种模式创建了一种包含单个对象和组合对象的统一接口，使得客户端可以以统一的方式处理单个对象和组合对象。统一的接口：组合模式提供了一个统一的接口来管理单个对象和组合对象。这个接口可以是抽象类或者接口。树形结构：组合模式允许客户以一致的方式处理单个对象和组合对象。例如，图形界面的组件（如窗口、面板、按钮）可以形成一种树形结构，其中每个组件既可以是单个元素，也可以是包含其他元素的容器。
2023-11-23 10:32:28
613
原创 桥接模式 (Bridge Pattern)
桥接模式（Bridge Pattern）是一种结构型设计模式，用于将抽象部分与其实现部分分离，使它们可以独立地变化。这种模式通过创建一个桥接接口，将抽象类和其实现类解耦，使得修改或扩展独立的抽象和实现变得更加容易。抽象化（Abstraction）定义抽象类的接口。它保持一个指向实现化对象的引用，并且由子类实现这个接口。精化抽象化（Refined Abstraction）扩展或细化由抽象化定义的接口。实现化（Implementor）定义实现类的接口。
2023-11-23 10:31:37
805
原创 适配器模式 (Adapter Pattern)
适配器模式（Adapter Pattern）是一种结构型设计模式，它允许不兼容的接口之间能够一起工作。这种模式涉及到一个单一的类，该类负责加入独立的或不兼容的接口功能。基本上，适配器模式就像现实生活中的电源适配器一样，它在两个不同的接口之间建立一个兼容的接口，使得原本由于接口不兼容而不能一起工作的类可以一起工作。类适配器：使用多重继承对一个接口与另一个接口进行匹配。类适配器通过继承来实现适配器功能。对象适配器：使用组合来连接两个不兼容的接口。
2023-11-23 10:30:45
193
原创 建造者模式 (Builder Pattern)
建造者模式（Builder Pattern）是一种创建型设计模式，它用于构建复杂对象的表示。这种模式将一个复杂对象的构建与其表示分离，使得同样的构建过程可以创建不同的表示。建造者模式通常用于解决复杂对象的逐步构建问题。分离复杂对象的构造和表示允许客户端不必了解内部组成的细节，就可以构造复杂的对象。通常用于创建具有多个部分的对象，特别是当这些部分需要通过多个步骤进行构建时。提供控制复杂性的方法。
2023-11-23 10:28:13
304
原创 抽象工厂模式 (Abstract Factory Pattern)
抽象工厂模式（Abstract Factory Pattern）是一种创建型设计模式，它提供了一种方式来封装一组具有共同主题的单个工厂，而无需指定它们的具体类。这种模式用于生成一系列相关或依赖对象的接口，而不指定它们具体的类。抽象工厂（Abstract Factory）定义用于创建一系列相关或相互依赖对象的接口，但不具体指定这些对象的具体类。具体工厂（Concrete Factory）实现抽象工厂的接口，具体化创建相应的产品对象。抽象产品（Abstract Product）
2023-11-23 10:27:14
297
原创 工厂方法模式 (Factory Method Pattern)
工厂方法模式（Factory Method Pattern）是一种创建型设计模式，用于解决对象创建的问题。它定义了一个创建对象的接口，但让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。抽象创建者（Creator）定义了一个工厂方法，通常是一个抽象方法，用于创建产品对象。创建者通常包含依赖于抽象产品的代码。具体创建者（Concrete Creator）实现了抽象创建者定义的工厂方法，用于返回一个具体产品的实例。每个具体创建者都负责创建一个特定类型的产品。抽象产品（Product）
2023-11-23 10:26:30
220
原创 原型模式 (Prototype Pattern)
原型模式（Prototype Pattern）是一种创建型设计模式，它用于创建重复的对象，同时保持性能。这种模式的核心思想是通过复制一个已存在的实例来创建新的实例，而不是新建实例并对其进行初始化。原型模式适用于创建复杂对象的情况，特别是当对象创建的成本比较高时，如需要进行繁琐的资源消耗型操作（例如，数据库或文件的读取操作）。原型（Prototype）定义用于复制现有对象以生成新对象的接口。具体原型（Concrete Prototype）实现原型接口的类，并提供复制自身的方法。
2023-11-23 10:25:47
591
原创 单例模式 (Singleton Pattern)
单例模式（Singleton Pattern）是一种常用的软件设计模式，用于确保一个类只有一个实例，并提供一个全局访问点来获取这个实例。单例模式主要用于控制对某个资源或服务的访问，确保整个系统中只有一个对象实例负责这些操作。单一实例该模式确保一个类只有一个实例存在。通常通过隐藏该类的构造函数，并提供一个静态方法来创建和获取这个唯一实例。全局访问点单例类提供了一个全局访问点，通过这个访问点可以访问唯一实例。这通常是一个静态方法，例如。自我实例化。
2023-11-23 10:24:52
694
原创 接口隔离原则 (Interface Segregation Principle)
接口隔离原则强调“不应该强迫客户程序依赖它们不需要的接口”。该原则要求将臃肿的接口拆分为更小且更具体的接口，这样客户程序只需要知道和关心它们真正使用的方法。
2023-11-23 10:22:13
30
原创 依赖倒置原则 (Dependency Inversion Principle)
依赖倒置原则指出高层模块不应该依赖于低层模块，二者都应该依赖于抽象；抽象不应该依赖于细节，细节应该依赖于抽象。简而言之，该原则要求在程序中使用接口和抽象类来构建弹性更强、耦合度更低的代码结构。
2023-11-23 10:21:50
36
原创 里氏替换原则 (Liskov Substitution Principle)
里氏替换原则由Barbara Liskov提出，它指出如果一个程序中的对象可以被它的子类对象无缝替换，而不改变程序的正确性和预期行为，那么这些对象就是符合里氏替换原则的。简单来说，子类对象应能够替换掉所有父类对象。
2023-11-23 10:21:10
49
原创 迪米特法则/最少知识原则 (Principle of Least Knowledge)
最少知识原则，也称为“迪米特法则（Law of Demeter）”，是一种软件设计原则，用来减少系统中不同类之间的相互依赖。根据这个原则，一个对象应该尽可能少地了解其他对象（只与直接的朋友通信）。
2023-11-23 10:20:38
53
原创 单一职责原则 (Single Responsibility Principle)
单一职责原则指一个类应该仅有一个引起它变化的原因。这个原则强调一个类应该只负责一个功能领域中的相应职责，或者可以理解为一个类应该只有一个改变的原因。
2023-11-22 22:00:00
266
原创 开闭原则 (Open-Closed Principle)
开闭原则是面向对象设计的核心原则之一，它指出软件实体（类、模块、函数等）应该对扩展开放，但对修改关闭。这意味着软件应该在不修改现有代码的前提下，允许其行为可以被扩展。
2023-11-22 17:52:01
59
原创 合成复用原则 (Composition/Aggregation Reuse Principle)
合成/聚合复用原则是指在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分；新对象通过向这些对象的委派达到复用已有功能的目的。这个原则是要求在软件设计中，尽量使用对象组合/聚合，而不是继承关系达到复用的目的。
2023-11-22 17:49:47
62
原创 Java设计原则和设计模式
目录第一部分：设计原则单一职责原则 (Single Responsibility Principle)开闭原则 (Open-Closed Principle)里氏替换原则 (Liskov Substitution Principle)接口隔离原则 (Interface Segregation Principle)依赖倒置原则 (Dependency Inversion Principle)合成/聚合复用原则 (Composition/Aggregation Reuse Principle)
2023-11-20 19:30:00
290
原创 DDD领域驱动设计-聚合
将实体和值对象划分为聚合并围绕着聚合定义边界。选择一个实体作为每个聚合的根，并仅允许外部对象持有对聚合根的引用。作为一个整体来定义聚合的属性和不变量，并把其执行责任赋予聚合根或指定的框架机制。
2022-11-07 10:15:29
732
1
原创 DDD领域驱动设计-值对象
通过对象属性值来识别的对象，它将多个相关属性组合为一个概念整体 。应该尽量使用值对象建模而非实体对象。即便一个领域概念必须建模成实体，在设计时也应更偏向于将其作为值对象容器，而非子实体容器。因为可以非常容易对值对象进行创建、测试、使用、优化和维护。
2022-11-07 10:14:07
552
原创 DDD领域驱动设计-实体
实体（Entity，又称为Reference Object）很多对象不是通过他们的属性定义的，而是通过一连串的连续事件和标识定义的。主要由标识定义的对象被称为ENTITY。
2022-11-07 10:10:02
1015
原创 DDD领域驱动设计-上下文映射
在使用REST时，客户端的领域服务将访问远程的开放主机服务，远程服务器以发布语言的形式返回，下游的防腐层将返回内容翻译成本地上下文的领域对象。对于下游客户来说，你需要根据自己的领域模型创建一个单独的层，该层作为上游系统的委派向你的系统提供功能。对于一些特殊的需求，你可以采用一次性的翻译予以处理，这样可以保持协议的简单性和连贯性。上下文映射图表现的是项目当前的状态，如果项目会在将来发生变化，你可以到那时才对上下文映射图做相应的更新。因此，在上游团队的计划中，我们应该顾及到下游团队的需求。
2022-11-03 13:22:41
648
原创 DDD领域驱动设计-战术设计
战术设计的产出可以是用 UML 表达的类图，需要细化到具体的属性，同时确保在代码级别可实现。它是战术设计中最重要和最复杂的模式之一，聚合基于另外两个战术标准，即实体和值对象。区分值对象与实体的区别在于，值对象是不可变的，并且没有唯一标识，仅由其属性的值定义。在整个领域模型中， 实体有自己独立的生命周期，这样可以让我们方便地获取到实体整个生命周期的变迁历史。工厂的出现，隔离了对象的创建过程。使用模块后， 可以有效地帮咱隔离关注点， 对应着Java中的包或C#中的命名空间，也总是遵循着统一语言。
2022-11-03 13:22:17
373
原创 DDD领域驱动设计-子域
你可以认为子域代表的是一个单一的、有逻辑的领域模型。通常，大多数的业务领域都过于庞大和复杂，难以作为整体来分析，因此我们一般只关心那些必须在单个项目中涉及的子域。子域可以用来逻辑地拆分整个业务领域，这样你才能理解存在于大型复杂项目中的。
2022-11-02 22:00:00
451
原创 DDD领域驱动设计-通用语言
那么，面对一个特定的业务领域，他们必然要首先统一对所面对的领域的认识，同时，在沟通的过程中他们要采用互相能够听懂的术语，只有这样才能高效沟通，最终形成无限接近于问题领域的实际可用的软件产品。我们在前面已经讨论过，软件设计整个过程都是知识的加工过程，不仅在需求分析时存在密集的业务领域知识，开发人员在做程序设计甚至编写代码是也可能产生新的知识，只有在业务专家和开发人员的沟通过程中，坚持使用通用语言进行沟通，才能高效地彼此分享知识，保持同步。如前面所说，业务模型是浓缩的、结构化的真实业务领域的反映。
2022-11-02 21:58:54
270
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人