Be landing DDD (5) - Design tactics
Summary
Benpian is DDD tactics chapter, which is the field of the event, the object fields, aggregate root discuss entity, the value of the object. DDD is also the series finale.
This part of the most controversial in our team, there are many menstrual stickers, such as the operation of the repository should be placed in the field service or field object.
Should the polymerization root exposed to the outside, or to turn into DTO. We discussed these issues for six months, and finally we reached a basic consensus in the current scale of operations,
these questions are not so important, it can be east west. So what does a big impact on the quality of the code. Practice of DDD, the team with the level of complexity of the business are closely related. Our experience does not necessarily apply your team. I would so much content on the tactics chapter of the article, and most of them are cited previous discussion, summary.
The reason lies deep down I did not think practice tactics chapter of our team to bring such a big change. Strategy papers that I consider more important.
DDD also off a series of articles a dozen articles, and is a summary of the main problems we encountered during landing team and solutions, DDD considered a complete closed-loop link from learning to practice landing, I hope for your inspiration. Of course, the biggest benefit of this process is certainly myself. Systemic thinking, summed up the problem, explained the problem is very helpful to enhance their thinking ability, and friends you can try.
Modeling
DDD turns out, is all for transactional programming, programming oriented database table of a reflection, the software design is obviously an object-oriented design, inheritance between objects need to be considered, polymorphism, composition.
Why is the actual coding process, procedural programming has become, why target only attribute is not a method, which is the blood loss model.
For more information about these types of programming can refer to Martin, "Patterns of Enterprise Application Architecture" Page110
So I personally think that the role of DDD has two, one is business-oriented, to help analyze the business model, business modeling. Another solution is for the domain, i.e. codes floor.
That the use of a standard that reflects the relationship between objects that OO programming.
At present mainly in the following categories DDD study
- On operational level of analysis, how to design methodology and abstract concept level
- Methodology of the service division, hierarchical codes, defined responsibilities
- DDD framework for discussion, such as jdon
Point 3 is basically how not widely discussed. I think what the future Niubi DDD framework does not appear to catch on. DDD is a modeling approach is for different business areas,
there are different floor plan in different teams, is no way to rely on a framework to constrain, not to put a single thing to unify. We like object-oriented design for the problem domain, abstracted from the
20 kinds of design patterns. These are the guiding ideology of design patterns, you can not come up with a framework to constrain people to use a design pattern based on the extension of this framework, in order to achieve unified code or reduce the
purpose programming difficult.
Previous article mainly larger context, more suitable for overall business analysis. That is the first point. The second major point of discussion today.
OO programming
DDD layering of your code, the definition of responsibility is essentially OO programming. Three basic elements OO is inheritance, polymorphism, composition. This is the depth of three abstract results. Not specific programming guide.
So we have design patterns, predecessors for the problem domain, summarized in addition to 24 kinds of design patterns, so when encountered similar problems, we can use the corresponding design patterns to solve the problem.
These underlying design patterns or to use inheritance, polymorphism, composition.
With that design patterns, why DDD it? Why use open source software DDD rarely seen it?
DDD or personal understanding for enterprise application architecture , is the uncertainty derives from the many business systems a set of specifications, it will surely be highly abstract. The open source software is mostly determined by comparing the field, such as database fields, middleware field. System architecture to solve such problems are usually more complex and scalable.
There are many online DDD engineering architecture, in the previous article I also mentioned, not repeat them here, look at this horse, I think very clearly shown the separation of duties
https://martinfowler.com/articles/ microservice-testing / # conclusion-summary
we look at the focus areas of a layer.
Field includes 3:00
Service areas
Target areas and service areas
Target areas
Dare intense discussion of aggregate root
Field events
Infrastructure Layer
The layers resources to provide services (such as databases, caching, etc.), decoupling of each layer, reduce the impact of external resources to change business logic.
to sum up
-
DDD China
http://ddd-china.com/look-back-2017.html video go to the site to see -
US group practice of
https://tech.meituan.com/2017/12/22/ddd-in-practice.html -
Practice box horse
https://zhuanlan.zhihu.com/p/42565478 -
cnblog blog park has a lot .net DDD practice articles
https://www.cnblogs.com/zhili/category/603514.html
http://www.cnblogs.com/daxnet/archive/2012/12/27/2836372.html -
jdon above series
https://www.jdon.com/ddd.html -
Framework (personally feel futile, take a look at reference)
rafy framework: http://zgynhqf.github.io/Rafy/articles/%E9%A2%86%E5%9F%9F%E5%AE%9E%E4%BD%93%E6%A1%86%E6% 9E% B6.html
-
Some related books pdf uploaded to Baidu network disk, you need the self-created.
Links: https://pan.baidu.com/s/1kGYk1dHbTAjBS4kd9s1VWw
extraction code: 36w4
Summary
本篇是DDD的战术篇，也就是关于领域事件、领域对象、聚合根、实体、值对象的讨论。也是DDD系列的完结篇。
这一部分在我们团队争论最多的，也有很多月经贴，比如对资源库的操作应该放在领域服务还是领域对象中。
聚合根应不应该暴露给外部，还是要转成DTO。这些问题我们讨论了大半年，最后大家基本达成了共识，在当前的业务规模下，
这些问题没那么重要，可东可西。不会对代码的质量有啥大的影响。关于DDD的实践，与团队的水平、业务复杂度息息相关。我们的经验并不一定就适用你们团队。我将战术篇的这么多的内容放在了一篇文章中，并且大部分都是引用之前的讨论、总结。
原因还是在于我内心深处并没有觉得战术篇的实践给我们团队带来多么大的改变。战略篇的是我认为更重要的。
DDD系列文章断断续续也有十来篇了，主要是总结我们团队落地过程遇到的问题和解决方案，算是DDD从学习到落地实践的一个完整的闭环链路，希望对你有所启发。当然这个过程受益最大的肯定是我本人。系统性的思考问题、总结问题、阐述问题是非常有助于提升个人思维能力，朋友们你们也可以尝试一下。
建模
DDD的出现，是大家对于事务性编程，面向数据库表编程的一个反思，明明软件设计是一个面向对象的设计，需要考虑对象之间的继承、多态、组合。
为什么到实际编码过程中成了过程性的编程，为什么对象只有属性没有方法了，也就是失血模型。
关于这几种编程的详细介绍可以参考Martin的《Patterns of Enterprise Application Architecture》Page110
所以我个人觉得，DDD的作用有两个，一个是面向业务的，帮助分析业务模型，进行业务建模。另外一个是面向解决域，即代码落地。
即使用一个规范能够反映对象之间的关系，即OO编程。
目前对DDD研究主要有以下类别
- 关于业务分析层面，如何进行概念层面的抽象和设计的方法论
- 关于服务划分、代码分层、职责定义的方法论
- DDD框架的讨论，比如jdon
第3点基本上没怎么广泛的讨论。我认为未来也不会出现什么牛逼的DDD框架能够流行起来。DDD是一种建模方法，是针对不同的业务领域的，
在不同的团队有不同的落地方案，是没办法靠一种框架来约束，来把一件不统一的事情来统一起来。就好比我们面向对象的设计针对问题域，抽象出来了
20多种设计模式。这些设计模式都是指导思想，你不能搞出一种框架，来约束大家使用某种设计模式就基于这种框架扩展，以此来达到代码统一或者降低
编程难度的目的。
前面的文章主要是比较大的方面，比较适合做整体业务分析。也就是第一个点。今天主要讨论第二点。
OO 编程
DDD的代码分层、职责定义本质上就是OO编程。OO的三大基本要素就是继承、多态、组合。这三个是深度抽象的结果。没法指导具体的编程。
于是我们有了设计模式，前辈们针对问题域，总结除了24种设计模式，这样遇到类似的问题时，我们可以使用对应的设计模式去解决问题。
而这些设计模式底层使用到还是继承、多态、组合。
那有了设计模式了，为什么还要DDD呢？为什么很少看到开源软件用DDD呢？
个人的理解DDD还是面向企业应用架构的，是在众多不确定的业务，系统中提炼出来的一套规范，这样必然是高度抽象的。而开源软件大多是领域比较确定的，比如数据库领域，中间件领域。解决这类问题的系统架构通常会更加复杂以及具有扩展性。
DDD的工程架构网上有很多，我在之前的文章也提到过，这里不再赘述，看下老马的这个，我觉得非常清晰的展现出来了职责分离
https://martinfowler.com/articles/microservice-testing/#conclusion-summary
我们重点看领域一层。
领域包含3点
领域服务
领域对象
领域事件
基础设施层
为各层提供资源服务（如数据库、缓存等），实现各层的解耦，降低外部资源变化对业务逻辑的影响。
总结
-
DDD中国
http://ddd-china.com/look-back-2017.html 视频去网站看 -
美团的实践
https://tech.meituan.com/2017/12/22/ddd-in-practice.html -
cnblog博客园有很多.net DDD实践的文章
https://www.cnblogs.com/zhili/category/603514.html
http://www.cnblogs.com/daxnet/archive/2012/12/27/2836372.html -
jdon上面的系列
https://www.jdon.com/ddd.html -
框架方面（个人觉得没啥用，参考看看）
rafy framework: http://zgynhqf.github.io/Rafy/articles/%E9%A2%86%E5%9F%9F%E5%AE%9E%E4%BD%93%E6%A1%86%E6% 9E% B6.html
-
Some related books pdf uploaded to Baidu network disk, you need the self-created.
Links: https://pan.baidu.com/s/1kGYk1dHbTAjBS4kd9s1VWw
extraction code: 36w4