Foreword
Will corrupt any human design, software system is no exception
Mystery corruption
With the increase in size and complexity of the system expansion, the system will slowly decay.
So a very simple change of address orders, will affect more than a dozen changes at the entire trading system.
How to solve the mystery of this corrupt it?
Reference Computer System Architecture:
A sophisticated computer system architecture includes: system software elements, the links between elements of the element itself has its own unique attributes.
So we can refer to the realization of computer system architecture in the architecture point of view.
Architecture Modeling
For the purpose of modeling architectures mentioned above, into the field of the drive.
Domain-driven business concepts around building a domain model to address complex business solutions, systems and the evolution of the problem is difficult to achieve by means of separation technology.
DDD bring different:
- The original technical point of view to look at the evolution of architecture perspective, the perspective of the business to convert to cut architecture.
- The complexity of the business comes from the art per se, in-depth field, to correctly identify deep-seated concepts and relations field.
- The domain knowledge to carry out structural expression while maintaining a consistent programming model, formed a DDD.
DDD mode based on the problem space
DDD mode based on the solution space
Boundary context
Cohesive specific functions defined by the boundary of the display, it is present in the domain model of context.
Context recognition process limits:
Domain Analysis
How driven by real business needs evolve DDD model it?
It can be field analysis using an event storm.
Process:
- PM, operations, RD come together
- Within a few hours to understand the complex field
- Mark simple UML
- Workflow and DDD perfect match
- Event stream evolution
System as an example to the electricity supplier
Event storm
event: PM concerned about the real events
such as: the customer's order has been issued, published commodity
explanation: the focus is on what domain model what has changed.
Command storm
command: by what activities the event
such as: user submits the order, open platform synchronized Goods
Description: Command Help our ability to define the system to provide both at the same time clear input on operational
command Source: Operation user UI interface, the external system call triggers, trigger regular tasks
寻找聚合
聚合：一组相关性领域模型的聚合，用来封装业务不变性，确保关联紧密的领域模型内聚在一起
如：订单和商品
聚合的目的在于业务内聚，强迫RD进行简化领域模型的关联，实现业务设计高内聚低耦合的目的
划分界限上下文
- 业务模型的问题是否同一个，是则放在同一个界限上下文中
- 如果一个聚合同时解决了多个问题，则需要定义不同的上下文确定解决特定问题
界限上下文之内可以自由选择架构模式，如MVC，CQRS，微服务，SOA等。
不是所有界限上下文都采用领域驱动方式，非核心子域可参考数据驱动下的面向过程编程。
提取出面向切面的聚合层，以工程技术因素为主要考虑点。
DDD的核心价值在于指导划分界限上下文。
DDD分层设计
领域模型建设思路：
- 业务与技术关注点分离，依赖倒置，内部不依赖于外部且外部可替换
- 接口适配器架构
- 防腐层建设，领域模型依赖稳定性
参考六边形架构：
架构目标：
- 独立于框架
- 与数据库分离
- 可测试性
- 与外部结构分离
- 与UI分离
架构原则：
- 关注点分离，切割不同层
- 依赖原则：外部依赖内部，依赖倒置
- 架构设计围绕用例
结合CQRS设计
CQRS：命令查询职责分离
将更复杂的领域模型拆分为读取和写入两部分。
将消息传递，数据日志同步，领域事件和事件溯源使用到特定上下文。
领域驱动实践
目前我们活动营销系统中，存在大量迭代需求都是针对运营需求所设计，需求本身具有复杂性和持续迭代性，故均已转换采用领域驱动设计方式实现。
对现有及可预期的玩法需求进行了逻辑抽象，提供了统一业务领域玩法模型，为运营提供统一玩法配置管理平台，进行玩法需求配置，经过领域系统内核进行集成，对用户输出统一玩法活动UI及流程。
在局部演进及扩展需求，采用元数据+大字段应对信息的不确定性，流程引擎+规则引擎构造玩法，DSL提供动态创建玩法资源配置的能力。
梳理事件风暴，抽象命令风暴，寻找履行命令的业务名词，对类似的名词玩法进行共性提取，做合适的抽象，同时建立通用语言描述及定义。
采用DDD分层架构+六边形架构+CQRS模型，使得系统具备面向领域驱动的演进能力。
最后
DDD不是银弹
哪些产品适用于DDD：
- 是否是复杂问题，或者子域内具有复杂性
- 业务是否重要且有很高的预期
- 是否可以让运营和PM介入
- 遵循迭代式的开放方法
领域模型好坏的标准：
- 模型反映了对于问题的抽象，抽象没有统一的标准
- 模型是迭代演进的，需要持续集成，改进
- 通用语言，领域模型和代码目标意图一致
更多交流：
