DDD领域驱动设计

一个软件功能或特征（feature）由一个或多个逻辑上相关的系统能力组成，这些能力可以为用户提供价值，并由一组功能需求来描述的。 许多业务分析师使用这些功能特征作为描述项目范围

我不是编码猴子，我是用代码解决业务问题，我需要了解这个业务问题（问题空间、领域问题上下文、为什么会有这个问题？）才能做好！ 作为一名开发人员/程序员，需要理解商业业务领域。 如果有人这么说：作为一名SWE（软件工程师），你们带来的只是关于通用计算的高效算法和数据结构的

Susanne 解释了她如何将 3 种不同的方法（Wardley映射、领域驱动设计和团队拓扑）联系起来，以设计和构建自适应系统以实现快速变化，以及为什么任何组织都必须拥有自适应系统。她是即将出版的《具有领域驱动设计、Wardley映射和团队拓扑的自适应系统：流程架构》一书的作者。 这三者之间的关系如

为什么我们系统的模块耦合度如此之高？是因为他们缺乏凝聚力吗？ （banq注：为什么人员在团队之间流动这么频繁？为什么团队之间开会如此频繁？是因为这些团队内部缺乏凝聚力吗？缺乏核心凝聚吗？） 案例： 有人说： 我们的系统是自 COBOL 和 FORTRAN 时代以来我们

在Airwallex，领域驱动设计（DDD）方法被用来指导如何对复杂的业务问题和系统设计进行建模。 在这篇博客中，我们试图全面介绍用DDD模式对支付系统进行建模的做法。 简介 支付系统是一个相当复杂和多变的系统，从订单、欺诈、通知、与各种支付方式的整合到资金清算和结算，涉及面很广。 在处理一个复杂的

数据库优先ORM模型（db first ORM）的定义：根据数据库自动生成代码，而不是根据代码生成数据库表，如 sqlc、sqlBoiler； 另外一种ORM模型是：根据代码自动生成数据库表，这种称为代码优先ORM模型（code first ORM模型），如GORM、sqlx和sql helper。

虽然事件确实无处不在，但受欢迎程度的增长似乎导致术语准确性的丧失。Apache Kafka 成为“事件总线”，所有异步消息都被声明为事件，使用事件流被声明为 Event Sourcing，像这样模糊不同的概念对架构讨论没有帮助。

SOLID原则是建立一个组件间低耦合度的系统的有力工具。 首先对这些原则做一个简单的回顾： [list] [*]SRP：单一责任原则 [*]OCP：开放封闭原则 [*]Liskov替代原则 [*]接口隔离

在构建 REST api 时，您会选择： 选项 A： [code]├── controllers │ ├── order.go │ ├── region.go │ └──

不久前，在一个并不遥远的IT世界里，架构师的角色被认为是不必要的。开发人员精通他们在大学数据库和网页设计课上学到的三层架构和ERD。精通对象建模、UML图解和文档的架构师只是臃肿的，是已逝的瀑布时代的遗物。 这在云计算时代已经完全改变了。现代的架构师不是画类图，而是制作使微服务之间相互作用的顺序和步

首先什么是敏捷？它来自哪里？ 我第一次遇到敏捷是在图书馆的工作中。我被雇来帮助一个新的数字学术中心落地，有时与图书馆的软件开发团队合作，建立工具来支持我们的项目。这个团队大约有六名成员，我马上注意到他们做事的方式与非技术人员不同。在会议上，他们不谈产品功能，而是谈 "用户故事"--描述功能的微小叙述

每家公司都有定义其程序、政策和业务功能的规则和流程。 这些规则支配着决策管理： 开发处理客户信用申请的应用程序 贷款申请和处理， 注册后会发生什么， 当客户被允许增加其透支额度时 这些决策背后是定义流程和条件的业务规则。 这些规则中的许多都被写下来，被写入程序，或者仅作为员工之间的常识存在，没有正式

我们目前还没有一种用于DI（Design Intent设计意图的简称，意图包括架构，业务规则）的语言。 当DI被嵌入到了代码中的会出现病症：如果你需要重构，那么很可能代码还没有被切分为DI和实现两个部分。 过多的细节走向了DI的对立面。 大多数语言都以他们有多少功能而自豪，而不是他们有多么少的功能。

交易型（Transactional ）应用是让你能完成某些任务的应用程序。这个任务可能很简单，比如检查一个正在运输的箱子的位置，或者给一个朋友或同事发送一个信息。该应用程序协助用户完成一个目标，但该应用程序本身并不是目标

学习领域驱动设计DDD、软件架构、设计模式、最佳实践的包含Javascript案例 该项目的主要重点是就如何设计领域驱动六边形