领域模型图(数据架构/ER图)
本文介绍基于四色原型法的领域建模过程，通过Moment-Interval（红色）、Part-Place-Thing（绿色）、Role（黄色）和Description（蓝色）四类原型，逐步构建风控系统的数据模型，并最终提炼出ER图，实现从业务流程到数据架构的转化。
如何把代码写的更优雅，你需要这一份代码精进书单！
黄小斜写了一年多的代码，渐渐地代码量也上来了，但是，代码写的多就是好吗，简单的数量堆积似乎并不能起到太好的效果，毕竟我们CRUD写多了，也不怎么需要架构设计，甚至连个设计模式都不怎么需要用到。如何开始代码精进之路，其实有很多的过来人早就已经给出了答案，今天就给大家推荐几本帮你精进代码的优质书籍，走过路过可不要错过哦~
复杂性应对之道——矩阵思维（多维度思考）
> You should not be a if-else coder, should be a complexity conquer. -Frank
# 前言
这篇文章，是对之前我在[《一文教会你如何写复杂业务代码》](https://www.atatech.org/articles/146064)说的“自上而下的结构化分解 + 自下而上的抽象建模”方法论的升级。因为在之前的方法论中，我
业务团队如何统一架构设计风格？
首次上线应用，面对业务框架搭建你是否曾感到无从下手？维护线上应用，面对大量历史包袱你是否正避坑不及深陷泥潭？为何同样是业务应用，不同人的设计风格千差万别？为何最初的设计经过多个迭代后总是面目全非？新人来到团队，怎样才能快速了解业务，不被大量技术细节折磨？如果你也有这些困扰，希望本文能提供些许帮助。
聊一聊中台和DDD（领域驱动设计）
本次分享价值：本次分享主要针对中台、微服务和领域模型的理念、本质及其构建方法论进行探讨。对领域分析的价值所在就是寻求“千变万化”中相对的“稳定性、第一性”，然后通过合理的架构分析及抽象隔离业务的复杂度和技术复杂度，隔离业务领域的稳定性和易变性，从架构上精巧、快速的支撑业务的变化。
DDD 领域驱动设计落地实践系列：工程结构分层设计
前面几篇文章中，笔者给大家阐述了 DDD 领域驱动设计的三大过程，重点围绕如何通过战略设计与战术设计进行 DDD 落地实践进行了详细的讨论，但是还没有涉及到工程层面的落地。实际上所有的这些架构理论到最后都是为了使得我们代码结构更加清晰，从而开发出 bug 少、扩展性强、逻辑清楚的应用。因此本文就是为了解决 DDD 领域驱动落地实践最后一公里问题，将我们分析出来的领域模型通过与工程结构的映射实现真正的落地。
项目终于用上了 DDD 领域驱动，太强了！
我在公司对支付业务、结算业务、资金业务使用DDD进行领域建模的两年，得到了许多好评，也面对过不少质疑，总体来说还是能收获不少，这对团队成员理解业务起着很大作用。近半年一直在研究DDD的落地实战，如今已修得阶段性成果，迫不及待与大家分享我的落地经验。
DDD分为战略设计与战术设计。一般来说，领域建模是属于战略层的，而DDD工程落地是属于战术层的，两者是否结合使用，视实际情况而定，比如传统的MVC架构也能使用DDD进行领域建模，DDD架构最好是先做DDD领域建模。
最新上线的一个微服务——内部交易中心，我们使用了DDD架构来落地，希望看完对大家有启发。
