在前面一篇介绍了如何通过DDD的思想，来调整单体服务内的工程结构，为微服务的拆分做准备。同时介绍了我们在进行微服务拆分的时候踩过的一些坑。 这篇介绍下我们最终的方案，不一定对，欢迎留言讨论。 微服务的一个重要特征就是自治性，如果依赖的服务多了，那么我们就享受不到微服务带来的好处…

谈到“架构”这两个字，会有好多的名词闪现，比如:分层架构、事件驱动架构、DDD、CQRS等。亦或者一堆的软件设计原则，如：KISS原则（Keep it Simple and Stupid）、SOLID原则(单一责任原则、开放封闭原则、里氏替换原则、接口分离原则、依赖导致原则)等…

最近重读Eric Evans的经典《领域驱动设计》，正如Eric提倡我们要去发现隐式概念一般，这次重读也让我发现了许多隐藏的DDD知识。恰好今日有朋友咨询我一些DDD问题，好似激活了触发器，随着问题的解答，我倒是在回答过程中又把这些知识梳理了一遍，才有了这篇杂记。 怎么看待DD…

伴随着互联网的快速发展，Web应用系统从面向企业内部发展到面向市场用户，业务的日趋复杂以及用户量的上升，那些曾经工作良好的单体应用开始遇到开发、测试、部署、发布各个方面的瓶颈，诸如扩展新增功能艰难、系统庞大难以维护、编译太耗时，发布流程太慢等问题困扰着开发团队。

得益于我司十几年前一帮大神数据库表模型设计的优异，一开始刚进公司的时候，很是惊叹。通过客户端配配属性，一个查询页面和一个资源实体的属性控件页面就生成好了。