日常开发过程中，尤其在DDD过程中，经常遇到VO/MODEL/PO等领域模型的相互转换。此时我们会一个字段一个字段进行set|get设置。要么使用工具类进行暴力的属性拷贝，在这个暴力属性拷贝过程中好的工具更能提高程序的运行效率，反之引起性能低下、隐藏细节设置OOM等极端情况出现。

!(https://oscimg.oschina.net/oscnet/ea8c4fbbc514341be35cc89aa9874e02209.jpg)作者：付政委成长总是来自于对未知领域的探索| 库布齐50公里穿行微信公众号：bugstack虫洞栈|关注获取源码沉淀、分享、成长，专注于原创专题案例，以最易学习编程的方式分

凯京科技成立已三周年，其技术架构经历从单体应用到微服务架构的升级，项目经历了从Spring到SpringBoot的改造，配置实现自动化，初步实现分布式，微服务，具备一定的容错能力，完成RPC框架Dubbo的定制化改造。目前，凯京科技在领域驱动方面也在不断的探索和实践，将DDD与微服务有机结合来构建系统，从而做到系统的高内聚、低耦合。1\.为什么选择D

摘要：一个Cope攻城狮用切身实例告诉你：Cope代码体验一时爽，BUG修改花半天。前言：此文为r0.7beta的操作实践，为什么我的眼里常含泪水，因为我对踩坑这件事爱得深沉。谨以此文献给和我一样踩坑的小伙伴，纪念踩坑时刻。!(https://pic2.zhimg.com/80/v20c653151d9ddd33a2a2622

我们有时候也会看到一些博客看到或者听到一些同事在说：这个业务有什么难的，不就是CRUD么？在软件生命周期初期，我们通过CRUD这种方式我们可以快速的实现业务规则，交付项目，但随着业务逐渐复杂，通过CRUD这种粗暴方式不可避免地会淹没业务核心规则，产生很多祖传（屎山）代码，系统交接的时候我们经常会听到，上一个开发是SB，或者自嘲自己是在屎山上面继续堆屎。

软件系统是通过软件开发来解决某一个业务领域或问题单元而产生的一个交付物。而通过软件设计可以帮助我们开发出更加健壮的软件系统。因此，软件设计是从业务领域到软件开发之间的桥梁。而DDD是软件设计中的其中一种思想，旨在提供一种大型复杂软件的设计思路和规范。通过D

本文以餐厅场景为叙事主线，以领域驱动为核心思想，结合架构设计与功能设计方法论。是从领域分析到落地的全过程案例，内容偏重于落地，因此不乏一些探讨，欢迎指正。文章较长、全程干货、耐心读完、必有收获。本文不针对餐厅的实现细节，重在探讨设计思想和方法。1、领域设计

FoxnicSQL中的Service有点像DDD中的Repository，但Foxnic体系里面又没有将Repository和Service区分开来，所以它更有点像两者的合体。但，他们的合与分本身是弹性的，具体还是要看业务场景的需要。在很多项目中，好多时候，Controller是Service的二传手，或许它也会成为Repository的三传手。所以，到底是单传还是二传或是三传还是要看项目、看场景。<br/FoxnicSQL中的Service就是将数据操作的目标具体化，它初始的样子就是针对单个表、单个实体的数据操作者。Service在使用时需要代码生成工具由数据表生成Po、Vo对象，Service接口以及接口实现。关于如何生成这些代码，我们不在此节展开。在此我们主要是了解如何使用Service已经为开发者提供的诸多功能

采用依赖倒置原则后的分层架构和六边形架构，实际上都符合整洁架构设计理念。但是六边形架构中使用端口与适配器，让应用程序能够以一致的方式被用户、程序、自动化测试、批处理脚本所驱动，同时能够让应用程序边界更加清晰，从而能更好地防止领域层和应用层逻辑泄露到外层。

前言趁着双十一备战封板，终于又有一些时间可以梳理一下最近的心得。最近这半年跟同事讨论比较多的是分层架构，然后就会遇到两个触及灵魂的问题，一个是如何做好分层架构，二是DDD在架构层面该如何落地。为了说好分层，我们需要了解架构的意义。良好的架构是为了保证一下两