我们正在错误的组织代码!

原文：[https://dzone.com/articles/we...]
翻译：祝坤荣

现在是时候停止像初学者教程里教你的那样来组织代码了。
​

现在，你应该在工作代码中捕捉领域知识并保护你的上下文不会被其他的知识上下文所污染。ProductRepository与BasketRepository有什么共同点？并没有。是在处理不同的问题，所以为什么把他们放在一起？
​

Product，ProductServie，ProductRepository是高度耦合的；为什么不把他们放在一起？他们是个整体 - 代码是一起变动的，并放在一起，精心的封装。越严格的限制你的存取级别，越能保证更少的机会出现不必要的依赖导致最后代码变成一锅粥。
​

我们要顶住把任何东西都变成public的诱惑！那是代码库变成一坨内部互相依赖的对象的原因。好好阻止你的包很重要。包中应该包含所有特定领域/上下文的类而且只提供一个特定的接口提供给其他的包来访问。然后，不像以前那样给每个类的每个公共方法写单元测试，而是只聚焦在组件的公共接口来写单元测试，覆盖所有的方法逻辑。[点这里看我关于有效测试的文章]
​

有单一，良好定义目的的组件是很容易理解和阅读的。组件的名称清晰的声明了他们的目的。
​

最基本的故事就是如果你的架构意图明显的映射到了代码上，可以让其更容易理解和维护。你的代码应该能反映出你画出的架构图。
​

一致性与耦合

在一起变化的代码应该放在一起。为一个共同目标服务的代码应该放在一起。一致性是个很简单的概念，我希望你也理解这点。
​

耦合是下一个重要的需要学习的内容。他是关于一个组件如何依赖或与另一个组件进行交互的。
(img)
一般来说，我们应该聚焦在高内聚和低耦合。通过高内聚实践单一职责原理。通过良好定义的接口来反转控制实现低耦合。
​

低耦合意味着跨组件间有更少的内部交互。他意味着一个组件在变更或替换时不会影响其他组件。
​

当软件被分解成更小的组件，这些组件不可避免的会与其他组件有交互，这需要清晰定义的边界来保证不会泄露领域。最终系统可以保持一致的交互但又彼此独立，边界分明。
​

这个故事最基本的内容就是如果我们可以在开发时有效的画出并实施边界可以让系统更容易理解和阅读。
​

演示

我写了一个使用模块化原则自己设计和实现了单体应用的工程。[点这里获取]。我也录了一个视频来说明工程中在文章里讨论的部分。
​
https://www.bilibili.com/vide...
​

---

本文来自祝坤荣(时序)的微信公众号「麦芽面包，id「darkjune\_think」
转载请注明。

交流Email: [e-mail]
微博:祝坤荣
开发者/科幻爱好者/硬核主机玩家/业余翻译