io.github.dddplus.dsl (DDDplus Framework 2.1.1-SNAPSHOT API)

接口概要
接口说明

IVirtualModel
逆向建模时识别出的当前代码里并不存在的业务对象.
枚举概要
枚举说明

KeyElement.Type
业务属性的分类.

KeyRelation.Type
业务对象间关系的分类.

接口概要
接口	说明
IVirtualModel	逆向建模时识别出的当前代码里并不存在的业务对象.

枚举概要
枚举	说明
KeyElement.Type	业务属性的分类.
KeyRelation.Type	业务对象间关系的分类.

注释类型概要
注释类型	说明
Aggregate	聚合/问题域，非DDD项目可以理解为模块.
KeyBehavior	业务对象的关键行为，只隶属于当前对象.
KeyElement	业务对象的核心属性：业务方可感知的最小完备集.
KeyEvent	关键领域事件，单向传递.
KeyFlow	关键业务逻辑流程，也可以理解为`KeyService`的某个方法.
KeyRelation	业务对象间关系.
KeyRelations	已过时不要直接使用.
KeyRule	关键的业务规则，控制逻辑.
KeyUsecase	已过时 Please use `KeyFlow.usecase()`

程序包io.github.dddplus.dsl的说明

Reverse modeling DSL: Object-Oriented Domain Model(As-Is -> To-Be) Re-Design without tech constraints.

背景：好的业务模型不仅对产品架构、开发有重大意义，也能够快速的帮助客户分析管理上的不足、业务处理上的漏洞、不合理需求的悖论等.

目标：提供一套模型描述语言，从代码提炼精粹的业务知识，指导并约束模型和系统演进.

路径：明确业务中关键问题，跨越(架构约束，技术限制)等造成代码难以直观表达模型的问题，面向对象地抽取和修正，形成与正向模型正反馈闭环.

价值：通过逆向工程方法揭示代码实现里体现的核心领域问题，发现essential problems：一方面关联代码实现，一方面关联通用语言.

《架构整洁之道》中的定义：软件架构是指设计软件的人为软件赋予的形状。

DSL标注过程，是无技术约束的OO二次设计的过程，是re-shape your code过程，是architecture discovery过程.

DSL标注过程，是Declarative Programming，而非Imperative Programming，关注描述问题和规则，而非实现步骤.

DSL标注过程，是对当前代码进行声明式编程的二次创作过程，它描述的问题的空间结构，结合版本控制就体现了时间维度.

DSL标注过程，是把领域知识注入代码的过程.

由于代码具有(可运行，包含完全细节，演进过程完整追溯，自我修复)特征，因此成为业务的唯一事实真相；但代码里有太多技术细节产生的业务模型噪音，导致代码里无法直观看到业务真相.

建模 = 图形 + 逻辑 + 现实的抽象，代码(一维的，局部的)，而模型(多维立体的，全局的)，逆向模型相当于动态的活地图

通过该DSL建立的逆向模型，(业务强相关，代码强相关)，它完成了业务与代码双向映射，最终实现(业务模型，代码实现)的持续一致.

Although much of the attention in business engineering is about process, most of these patterns are static type models. I like to think of type models as defining the language of the business. These models thus provide a way of coming up with useful concepts that underlie a great deal of the process modeling. 在面向对象开发过程中很重要的原则：要设计软件，使得软件的结构反映问题的结构。

 DomainModel      -->   CodeImplementation
     ^                        |
     |                        V
 KnowledgeCrunch  <--   ReversedDomainModel

字段级：
- KeyElement
方法级：
类级：
包级：
- Aggregate

显式标注，不标注则视为非模型要素
KeyElement.name()，KeyBehavior.name()等，修正关键概念名称
KeyFlow.actor()，重新分配行为职责
IVirtualModel，识别代码里缺失的关键职责对象，并在模型层建立

模型是否直观完整表达出了业务核心知识
产品、业务方是否能看懂
日常开发，是否从模型中来，到模型中去闭环

业务需求 -> 从模型入手 -> 模型修改 -> 设计评审 -> 代码实现(依据活地图) -> 自动生成逆向模型，验证设计与实现一致性
围绕模型，持续构造易于维护的软件
- 就大致理解了代码结构
- 讨论需求时，研发就能容易明白需要改动的代码，评估工期和风险
- 改功能就是改模型，改模型就等同于改代码，改代码就是改模型
使用该模型的典型场景：
- 我在网上看到一个开源ERP系统，如何快速掌握其核心设计？
- 我是业务中台负责人，在与多条线BP合作扩展开发时，他们如何快速掌握我的设计，如何快速承接业务开发
- 公司新找一批外包人员，如何让他们了解系统
- (业务方，产品，研发，架构)，他们统一的模型张什么样，它存在吗
- 我是架构师，新进入一个团队，里面有十几个大型遗留系统，如何快速掌握它们，并识别核心问题

ArchiMate

BPMN

C4 Model

UML

TOGAF ADM

SysML

4+1 View Model

DSL

简单，门槛低
与代码强关联
具有修正机制

它在揭示整体结构上表现很好，但貌似缺乏要素间通信的表达力？
- DDDplus is not going to re-invent the wheel
- IDEA Sequence Diagram plugin/BPMN等工具已经具备这类能力
- CallGraphReport会绘制关键方法的调用关系
业务约束/规则上貌似只是罗列，缺少场景表现力？
- ISpecification已经可以自动追溯了，因此没必要在逆向模型里体现，否则只会产生不必要噪音
- 可视化的前提是：它真的可视
扩展能力如何可视化表达？
- 已经有了，please see DomainArtifacts
逆向模型貌似已经把代码变成结构化的数据了，我可以保存到数据库以产生下游应用吗？
- Sure!
- please see ReverseEngineeringModel，which can be defined with multiple RDBMS tables

另请参阅:: 面向对象设计的逆向建模方法和开源工具, Requirements for integrating software architecture and reengineering models, 面向领域驱动设计的逆向建模支持方法, MoDisco

程序包 io.github.dddplus.dsl

程序包io.github.dddplus.dsl的说明