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

当初是时候进行像初学者教程里教你的那样来组织代码了。
​

当初，你应该在工作代码中捕获畛域常识并爱护你的上下文不会被其余的常识上下文所净化。ProductRepository 与 BasketRepository 有什么共同点？并没有。是在解决不同的问题，所以为什么把他们放在一起？
​

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

咱们要顶住把任何货色都变成 public 的引诱！那是代码库变成一坨外部相互依赖的对象的起因。好好阻止你的包很重要。包中应该蕴含所有特定畛域 / 上下文的类而且只提供一个特定的接口提供给其余的包来拜访。而后，不像以前那样给每个类的每个公共办法写单元测试，而是只聚焦在组件的公共接口来写单元测试，笼罩所有的办法逻辑。[点这里看我对于无效测试的文章]
​

有繁多，良好定义目标的组件是很容易了解和浏览的。组件的名称清晰的申明了他们的目标。
​

最根本的故事就是如果你的架构用意显著的映射到了代码上，能够让其更容易了解和保护。你的代码应该能反映出你画出的架构图。
​

一致性与耦合

在一起变动的代码应该放在一起。为一个独特指标服务的代码应该放在一起。一致性是个很简略的概念，我心愿你也了解这点。
​

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

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

当软件被分解成更小的组件，这些组件不可避免的会与其余组件有交互，这须要清晰定义的边界来保障不会泄露畛域。最终零碎能够保持一致的交互但又彼此独立，边界明显。
​

这个故事最根本的内容就是如果咱们能够在开发时无效的画出并施行边界能够让零碎更容易了解和浏览。
​

演示

我写了一个应用模块化准则本人设计和实现了单体利用的工程。[点这里获取]。我也录了一个视频来阐明工程中在文章里探讨的局部。
​
https://www.bilibili.com/vide…
​

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

交换 Email: zhukunrong@yeah.net
微博: 祝坤荣
开发者 / 科幻爱好者 / 硬核主机玩家 / 业余翻译